Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critiquing Facebook's new PHP spec

blog.circleci.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Critiquing Facebook's new PHP spec

#61

Post by chriswarbo »

wvenable wrote: post #60
chriswarbo wrote: post #56

Earlier quoted context omitted.

> You get strings from the browser Really? I thought browsers sent HTTP requests. > you get strings from the database Really? I thought databases returned tables, ie. ordered collections of rows with individually-typed columns. > and strings from the file system. Really? I thought filesystems returned streams of bytes. Just because lots of values can be represented by strings, doesn't mean they are strings. "X is a s…

Much of the reasons for PHP being stringly typed are historical. For example, extremely old database drivers used to stringify everything so you didn't get individually-typed columns. An HTTP request, specifically an encoded GET or POST, all values from the browser are strings. A file system is a stream of bytes, but many common web file formats stringify all values (JSON, XML, INI, etc). > Strings are an implementat…

> > Strings are an implementation detail which should be abstracted over.

> That's exactly what PHP does -- PHP doesn't care what representation a value has. But that is also then the source of it's strangeness.

I don't know if that's a valid use of the term "abstract", but it's certainly not what I meant. Rather than passing around low-level values for as long as possible, and only interpreting their contents when forced to (eg. when "+" forces them to be treated numerically); instead, I meant interpreting values as soon as possible so that they're treated as the appropriate type.

> An HTTP request, specifically an encoded GET or POST, all values from the browser are strings.

Again, they're only represented as strings. When I use an "order" parameter in my application, I want it to be an Order. I don't want it to be NULL. I don't want it to be a string which may-or-may-not be the numeric ID of an Order which may-or-may-not be stored in my database. If it's not an Order (eg. if the "readOrder" function I declared as the handler for this parameter returned [] instead of [$the_order]), the request is malformed so a HTTP 400 response should have been sent. My application should never even start if the data it needs isn't available.

Of course, that's exactly what "dependency injection" is in the OOP world; it's also a major use-case for the Reader monad in the Functional Programming world.

Re: Critiquing Facebook's new PHP spec

#62

Post by wvenable »

chriswarbo wrote: post #61
wvenable wrote: post #60

Earlier quoted context omitted.

Much of the reasons for PHP being stringly typed are historical. For example, extremely old database drivers used to stringify everything so you didn't get individually-typed columns. An HTTP request, specifically an encoded GET or POST, all values from the browser are strings. A file system is a stream of bytes, but many common web file formats stringify all values (JSON, XML, INI, etc). > Strings are an implementat…

> > Strings are an implementation detail which should be abstracted over. > That's exactly what PHP does -- PHP doesn't care what representation a value has. But that is also then the source of it's strangeness. I don't know if that's a valid use of the term "abstract", but it's certainly not what I meant. Rather than passing around low-level values for as long as possible, and only interpreting their contents when f…

That is sort of the opposite of abstracting over the type but I get what you mean. I totally agree that interpreting values as soon as possible into the appropriate types is superior. I'm a big proponent of fail early. PHP, as with many scripting languages, are designed for short-term programmer convenience over long-term programmer convenience. Which given it's history and the original tasks it was designed for, that makes sense.

But PHP is moving in the direction of interpreting types quickly and failing early. Specifically, scalar type hinting seems like an almost certainty once there is an agreement on the semantics.

Re: Critiquing Facebook's new PHP spec

#63

Post by timdierks »

coldtea wrote: post #36
timdierks wrote: post #32

I can see the appeal of allowing behavior variant from Zend in areas where there is a big benefit, and I like the approach of defining these areas as "implementation-dependent" rather than specifying one or the other. However, it seems to me that some of these are in areas where PHP code would need to know the runtime behavior of the platform they're on; the alternative is just to avoid all such areas ("there be drag…

> Why not have the specification allow runtimes to expose their choices of behavior into the runtime to allow code to determine what their platform does? Because the idea is that it should be transparent to the code. If you start doing that you get into mess like the "feature sniffing" BS JS does in browsers, IFDEFs etc... So, which of these specifically seem to you to be "on areas were code would need to know the ru…

I don't know the details of PHP, but it seems to me that all the areas that are referred to as "implementation-dependent" are code-observable: e.g. the deferred array copying decision discussed in the critique: if your code depends on a behavior, you'll get different results on the other platform. So if you want to be portable, you need to sniff the behavior and take a different route on the alternate platform, or you need to avoid the quicksand in the first place.

Re: Critiquing Facebook's new PHP spec

#64

Post by jondum_bau »

aaronem wrote: post #58
jerf wrote: post #45

Earlier quoted context omitted.

"Would that include not adding:" A whole bunch of completely standard features to add to a mutable-state dynamic scripting language, almost each and every one of which had been successfully added to a mutable-state dynamic scripting language before PHP did it? Of course not. (I'm not sure about that last one, though I suspect one could find a version of Perl early into its reference experimentations that would have a…

> Even today, I'm not sure if a function that returns a list (not list ref) can be directly dereferenced into via [] notation. Unless it's changed very recently, you cannot; you have to wrap it in an arrayref, e.g. [returnsAList()]->[0]

all lists can be sliced with the [] notation.

the above example would returnsAList, put it in a new array reference, then dereference it. probably not want you want.

To get the first item from the sub with [] notation would be (returnsAList)[0]

perl -e 'sub returnsAList { return 0..5 }; $v = (returnsAList)[3]; warn $v'

Re: Critiquing Facebook's new PHP spec

#66

Post by coldtea »

timdierks wrote: post #63
coldtea wrote: post #36

Earlier quoted context omitted.

> Why not have the specification allow runtimes to expose their choices of behavior into the runtime to allow code to determine what their platform does? Because the idea is that it should be transparent to the code. If you start doing that you get into mess like the "feature sniffing" BS JS does in browsers, IFDEFs etc... So, which of these specifically seem to you to be "on areas were code would need to know the ru…

I don't know the details of PHP, but it seems to me that all the areas that are referred to as "implementation-dependent" are code-observable: e.g. the deferred array copying decision discussed in the critique: if your code depends on a behavior, you'll get different results on the other platform. So if you want to be portable, you need to sniff the behavior and take a different route on the alternate platform, or yo…

>are code-observable: e.g. the deferred array copying decision discussed in the critique: if your code depends on a behavior, you'll get different results on the other platform.

I don't see how the "deferred array copying" ever leak to the program you write. Copy-on-write and such is a classic example of implementation detail that the higher layer is not concerned about.

Re: Critiquing Facebook's new PHP spec

#67

Post by hrktb »

wvenable wrote: post #16
leeoniya wrote: post #12

Earlier quoted context omitted.

what threw me personally about empty() is that it doesn't invoke magic getters: "__get".

That's not true, empty() will call __isset() first, and only if it returns true will it call __get(). This is because empty() is the compliment to the isset() function. There is no reason to use empty() over the not (!) operator unless there is the potential your property doesn't exist.

> There is no reason to use empty() over the not (!) operator unless there is the potential your property doesn't exist.

I think empty() is one of the "magic" parts of php that requires to know what it does really really well before trying to use it, especially before 5.5. For anyone learning the language, avoiding empty() altogether might be best/

One of the most interesting thing IMO is the suppression of any error occuring during the test. I.e "empty($object->is->null->but->we->call->nine->levels->of->properties)" won't generate any warning nor exception about calling properies on a null object, it just returns "true". It's powerful, while being a potential trap for anyone not aware of this behavior.

Re: Critiquing Facebook's new PHP spec

#69

Post by timdierks »

coldtea wrote: post #66
timdierks wrote: post #63

Earlier quoted context omitted.

I don't know the details of PHP, but it seems to me that all the areas that are referred to as "implementation-dependent" are code-observable: e.g. the deferred array copying decision discussed in the critique: if your code depends on a behavior, you'll get different results on the other platform. So if you want to be portable, you need to sniff the behavior and take a different route on the alternate platform, or yo…

> are code-observable: e.g. the deferred array copying decision discussed in the critique: if your code depends on a behavior, you'll get different results on the other platform. I don't see how the "deferred array copying" ever leak to the program you write. Copy-on-write and such is a classic example of implementation detail that the higher layer is not concerned about.

Read the post; apparently Zend doesn't make deep array copies in some circumstances.

The quote from the spec is "Unlike conforming deferred string copy mechanisms discussed in §§ that must produce the same observable behavior as eager string copying, deferred array copy mechanisms are allowed in some cases to exhibit observably different behavior than eager array copying."

Note the phrasing "observably different behavior".

Re: Critiquing Facebook's new PHP spec

#70

Post by pbiggar »

timdierks wrote: post #69
coldtea wrote: post #66

Earlier quoted context omitted.

> are code-observable: e.g. the deferred array copying decision discussed in the critique: if your code depends on a behavior, you'll get different results on the other platform. I don't see how the "deferred array copying" ever leak to the program you write. Copy-on-write and such is a classic example of implementation detail that the higher layer is not concerned about.

Read the post; apparently Zend doesn't make deep array copies in some circumstances. The quote from the spec is "Unlike conforming deferred string copy mechanisms discussed in §§ that must produce the same observable behavior as eager string copying, deferred array copy mechanisms are allowed in some cases to exhibit observably different behavior than eager array copying." Note the phrasing "observably different beha…

It is definitely observable.
Post reply on HN