Critiquing Facebook's new PHP spec
blog.circleci.com
blog.circleci.com
Is it even worth it to leave room for a threaded PHP? At this point that would de facto be another language anyhow... the changes required to add threading to a language like PHP [1] 20 years after it was born are too insane to even think about. It would be so many years before it was stable enough to begin building any sort of library infrastructure that would make it into any sort of common use that the language would probably be on the way out by the time this gauntlet could be run. See Perl's experience with trying to add threading.
It would certainly require another specification document anyhow.
I'm of the opinion that languages around the 10 year mark (which PHP is obviously well past) really ought to focus on becoming the best X they can be, rather than chasing the tail lights of constantly-moving best practice. Seems like you're better off just making PHP be the best PHP it can be rather than try to add threading in to the mix. PHP certainly simply isn't going to be able to compete with existing languages that build some sort of solid threading story in from day 1, and, frankly, it shouldn't try. (And most of those languages simply can't compete with PHP on its home turf, after all.)
[1]: Mutable-state imperative dynamic. Basically, the answer to the question "What's the hardest sort of common language to add threading to after the fact?"
I'm of the opinion that languages around the 10 year mark
(which PHP is obviously well past) really ought to focus on
becoming the best X they can be, rather than chasing the
tail lights of constantly-moving best practice.
* Anonymous functions and closures
* Namespaces
* Late static binding
* Dynamic dispatching to static methods
* Rackup/SimpleHTTPServer-like web server
* "finally" in exception-handling
* Being able to call foo()[0] instead of the clumsy
assign-then-dereference two-step.
(I used to use PHP. I dislike it as a language, but I have nothing against them continuing to improve it like they have over the last nine years.)
PS: PHP already supports threading via a PECL module. http://php.net/manual/en/class.thread.php
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 an equivalent problem. Even today, I'm not sure if a function that returns a list (not list ref) can be directly dereferenced into via [] notation. Or at least it's klunky. And let me clarify that I do mean added to an existing language, not programmed in from the beginning, which is a very different problem.)
I'd also add generators into that list.
Adding pervasive threading is a different story. Adding threading to a mutable-state dynamic scripting language has a long and sordid history... even when it is nominally successful (as in Python) it is still not very useful, and at times it has been simply a failure (like Perl).
As another example, though, I would suggest the principle would be firmly against trying to add Hindley-Milner typing to the language, or making some big move in an immutable direction. That's not PHP... that's not "mutable-state dynamic scripting language". I'd also suggest against burning any time in trying to make PHP not a "scripting" language anymore, on the grounds that Hack is the right approach; create a companion language that may integrate well, may even still be a "dialect" of PHP, but is not "PHP" anymore, and can do the non-scripting work without actually trying to bodge that into PHP proper.
"PS: PHP already supports threading via a PECL module."
Yeah. Perl "supports" threading too... for sufficiently small definitions of "supports". Unsurprisingly, when I googled "PHP thread" (without quotes in the search), once you get past what are for me the first three links which are for the documentation itself, the remainder of the results consist of people asking and/or explaining why you can't trust it or use it. Compare with the Google search for "perl thread". (Pretty much the same except with Perl, even the documentation warns you away from using it.)
PHP is a mutable-state dynamic scripting language. It can continue importing anything it likes from that realm as all the mutable-state dynamic scripting languages continue to converge on the same basic core of features, which I have in the past called CLispScript but really there's any number of things you could reasonably call it. Good threading support is not in that core set of features. The history of other extremely similar languages extremely strongly suggests it would be little more than a staggeringly enormous waste of time.
But of course, if PHP would like to ignore that history, go nuts. I see no reason to believe that its internals and API are so especially cleanly designed that threading will be a breeze to add on, but hey, go prove me wrong. (That might sound like a sarcastic snipe at PHP at first. And I won't lie, I don't like PHP. But the truth is simply that adding threading on 20 years later is insanely difficult if you haven't been planning for it all along, and that's pretty much regardless of the underlying language. If you have been planning for it it's merely very difficult. So very, very many things will fundamentally depend on the implicit lock that you get by everything being single-threaded that you don't even realize it until you try to add the threading on and realize just how thoroughly the assumption has been baked into the VM, the runtime, every library, every framework, every binding... everything.)
For another "see also", look at Javascript, another fairly similar language to PHP in the grand land of programming languages (mutable-state dynamic scripting language). There is a reason we have "Web Workers" and we don't have "Javascript Threading", and it isn't all "browser".
Incidentally, since for I don't even know what reason HN has somehow decided that my first post is unworthy, do note that it's a serious engineering question. Spending design capital on "keeping things safe for future threading" is not free, and if there really isn't any chance that PHP is going to be threaded in the future, you're better off claiming the bounty of staying single-threaded in the spec than complexifying it with things that will never be used, because being able to guarantee single-threadedness is actually a big win in its own way... if you've got it, use it. And, again, the actual history of adding threading to this sort of language is not very promising at all.
(Edit: A bit more searching finds a few people suggesting that PHP threading may be usable, though it made the transition to that quite recently. It still doesn't sound like it's something I'd touch after all the other times I've been burned in other environments with similar level of promises and experiences. YMMV.)
Unless it's changed very recently, you cannot; you have to wrap it in an arrayref, e.g.
[returnsAList()]->[0]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'
As for cursors - Zend Engine actually supports both internal and external cursors for arrays, but there's no user-level access to that. Extensions though use it all the time. So given threading would be implemented on C level, it could potentially use external cursors. Though, as I mentioned, there would be problems well beyond cursors to deal with in that case. E.g., since arrays are mutable, one would be first required to ensure both threads actually somehow accessing the same object and it hasn't disappeared or mutated unrecognizably from under them. That would require much more effort than a couple of cursors.
I'd expect Zend to keep supporting RAII, but I doubt new implementations will - its a real drag on building better GCs, and that can be as much as half the performance of a program.
Before getting into technical nitty gritty, I wanted to clarify that the spec in its current state is a draft offered to the PHP community as a starting point for specifying the PHP language. It now belongs in the php-src repository and can be updated through the standard commit processes for that repository as the community sees fit. Some decisions about specificity were made for the initial draft, but these decisions are by no means final and the hope is that the community will settle on what's right for the PHP ecosystem overall.
Regarding RAII, I'd argue that __destruct methods in PHP are a bit different than stack-allocated variables in C++. Stack allocated variables in C++ have a strictly defined lifetime based on the scope of the variable. In PHP on the other hand, objects are heap allocated and when they are destroyed is not as well defined. For example, you can have a cycle of two or more objects pointing to each other that are unreachable (i.e. cyclical garbage), and it such cases any __destruct methods for these objects are not immediately invoked when the objects become unreachable. I considered requiring refcounting-based automatic memory management for the initial draft of the memory model, but describing in detail cyclical garbage felt really implementation specific and so at a gut level it seemed better to not require RC-based automatic memory management and see how people reacted.
Based on my personal programming tastes, I'd argue that try/finally is a cleaner, more robust way to ensure certain cleanup happens when a scope is exited rather than relying on __destruct. However, I understand that there are some PHP programs out there that rely on __destruct being invoked eagerly in non-cyclical-garbage cases, and that such code will probably exist in the wild for a quite a while regardless of whether try/finally is "superior" or not. I'm curious to see how this issue settles over time.
For the record, HHVM uses RC-based automatic memory management and will eagerly call __destruct on objects that become unreachable that are not part of cyclical garbage. The initial choice to be a bit more liberal about reclamation was not essential to make sure that HHVM was compliant with the spec.
I personally prefer RAII to finally for object-related cleanup because finally is fallible. If you have a File object instance whose destructor calls fclose() automatically then I don't have to remember to call a Close() method inside a finally block. It happens automatically. But if you don't have RAII then you must remember to put in try blocks and finally clauses everywhere you create an instance. Multiply that by every database connection, network connection, and file and that is a lot of work and potential to miss something. And finally doesn't work at all if your object lifetimes aren't tied to scope.
Finally is inferior to RAII in almost all cases except where you aren't using nicely defined objects. If you use an fopen() call directly, finally is your only recourse to fclose() it properly. The only criticism of RAII is that does limit concurrency and garbage collection options.
I agree with your points about "finally". It can definitely be a bit clunky, and this is why some languages have introduced scoped cleanup constructs such as C#'s "using" statement, Python's "with" statement, and D's "scope" statement. I guess what I was getting at with my original comment is that I feel scoped cleanup constructs are a better way to go vs. relying on heap allocated things being reclaimed at a certain time, given that the lifetime of a heap allocated thing can depend on non-local state outside of the current function/method.
Even scoped cleanup constructs are problematic. I often forget to use them when needed in C# and it's often hard to tell if an object needs it. Furthermore, implementators of IDiposable in C# have to write a lot of boilerplate code[1] to do disposable correctly and cascade disposing to every contained object (again determining if it's necessary). It's also not change friendly -- a class might not need to be disposed today but if changed later all the existing instantiating code won't have guards.
I'm not sure why you think the the lifetime of heap allocated objects under RAII is an issue -- they'll just clean themselves up when they're not needed. It's much less worry and code. What issue do you think exists?
As for Scoped cleanup constructs, they are just hack for languages that can't do RAII -- they have no other benefit.
[1] http://msdn.microsoft.com/en-us/library/b1yfkh5e%28v=vs.110%...
The spec, as it stands, is flawed. Any removal of RAII should be left to major version (e.g. PHP7). Since this spec is meant to represent the current state of PHP, it's completely incorrect in this area.
(I take no position on RAII being useful or not, I don't write PHP for a living).
http://php.net/manual/en/language.oop5.decon.php#language.oo...
"PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++. The destructor method will be called as soon as there are no other references to a particular object, or in any order during the shutdown sequence."
It's very common to rely on this behavior to do cleanup as PHP did not have a finally clause (like C++) until recently.
Anyway, it's a slightly pedantic point, so I'm probably not contributing much to the conversation here :)
PHP Code > PHP Spec > PHP Engine
To be fair, the JS spec may say those things but no modern JS engine actually does it that way. Despite the wording, "must appear to..." is the common interpretation of that spec. It is nice that this one makes that explicit, though.
> I read this as saying that when a variable dies, you must immediately clear it up. I suspect that this will make the GC a little less flexible than it has to be.
I think the key reason for this is that objects have deterministic destruction in PHP which allows for the RAII pattern. This is in contrast with garbage collection in Java or C# where finalizers aren't called immediately (or sometimes at all) and the RAII pattern is impossible.
I suspect if you could leave memory lying longer around as long as you destructed objects and resources immediately but there probably isn't any advantage to that. But changing the destruction characteristics would break code that depends on it.
Objects have different lifetimes, and the spec actually allows the destructors to be run anytime between the object being dead and the program ending. So it looks like there won't be any RAII here.
It doesn't make sense to force very specific memory lifetimes for variables and then also not do it for objects.
> Later, if a VStore or HStore becomes unreachable through any existing variable, they become eligible for reclamation to release the memory they occupy. The engine may reclaim a VStore or HStore at any time between when it becomes eligible for reclamation and when the script exits. Before reclaiming an HStore that represents an object, the Engine will invoke the object's destructor if one is defined.
I'll put it in now. Thanks - and great catch!
[0] it doesn't work when there's a cycle for instance
No part of that phrase matches reality.
> Cycles don't really affect RAII in meaningful way.
Which is irrelevant because once again what PHP has is not RAII it's reference counting, same as CPython and Objective-C. And because it's refcounting it does have an impact: objects involved in or linked from a cycle are not immediately cleaned up once the cycle goes out of scope because all objects still have a refcount of at least 1.
Cycles which, by the way, PHP did not bother breaking until 5.3: http://php.net/manual/en/features.gc.collecting-cycles.php so these objects would live until process death.
It's true. When exception handling was added to PHP, RAII was absolutely factored into the design. This is why it didn't get a finally clause to start with -- it's unnecessary.
> Which is irrelevant because once again what PHP has is not RAII it's reference counting
http://www.hackcraft.net/raii/
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...
If you have reference counting or stack allocated objects than you can do RAII. You seem to be confused as what these terms mean -- they are not contradictory, they are complimentary. Ref counting allows RAII.
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 dragons here") or to give up on portability and be implementation-dependent, in which case it seems to me that there's not much value in having a PHP standard (other than as a base document on which to build the Zend or HHVM specifications).
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? Of course, one can probably write tests for these behaviors and build a library, but it seems like it would be better to just delineate the alternative behaviors and put them into the ABI.
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 runtime behavior"?
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.
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".
When I ran your code I got "PHP Notice: Undefined offset: 1"
If I removed that line then I got "2 3" which seemed wrong to me since those two variables should have been aliases to the same thing. But copying the values instead of the reference seems slower, not faster.
$a = new Point(1, 3)
and
$a =& new Point (1, 3)
Answer: I forget! I think it’s that the next assignment to “$a` will do something odd, but honestly I don’t remember the subtleties.
So what is the difference exactly?
It was expected that these strings contain numbers and that you should be able to rationally use them as numbers without conversion. So "10" > "5" returns true in PHP where as that would be false in most other languages. The underlying representation of the value (sequence of characters, 2s compliment binary, or IEEE 754 double) means nothing in PHP; they are all supposed to be equivalent. So "12", 12, and 12.0 are the same and "0" and 0 are the same.
The consequence of this design ripples through to every aspect of the language. And it ripples down to the implementation of empty. Empty(0) is true. So therefore Empty("0") is also true. The fact that one is an integer and the other is a string is not a distinction that exists in PHP. It's super weird and unexpected but it's not illogical given the rules of the language.
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 string" is the cause of:
* XSS vulnerabilities: "HTML is a string" and "user input is a string"; why not concatenate them?
* SQL(/shell/eval/etc.) injection vulnerabilities: "SQL queries are strings" and "user input is a string"; why not concatenate them?
* Multilingual issues: "byte streams are strings"
* Malformed requests/responses (ie. 'message not understood', invalid markup, etc.): "requests/responses are strings"
I know you're stating the rules of PHP, rather than a personal opinion, but I think it's important to reiterate this point whenever "x is a string" comes up. Strings are an implementation detail which should be abstracted over. After all, strings themselves are just an abstraction over bytes/words.
> 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.
> 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.
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.
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.
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.
Just use the following if you really want to account for strings containing the number 0.
(!isset($var) || $var === false);
if ($a == "") { ... }
Nope! "empty" is an operator too:
var_dump(array_map('empty', [null, '', 5, false]));
PHP Warning: array_map() expects parameter 1 to be a valid callback, function 'empty' not found or invalid function name
NULL
If you expect a string '0', simply check strlen($str) > 0. If the value could be numeric, use a (string) cast.
You used affect when you should have used effect. They probably don't teach that in the CS PhD program:)
Of course my post may be subject to Muphry's Law. But still. If you're going to spend so much time establishing your credibility, do you really want to ruin it by demonstrating you don't have a basic understanding of English grammar?
"I noticed a typo -- <phrase containing the word 'affect'> should be <phrase containing the word 'effect'> instead. And since I'm not being a smartass, I don't have to go through all the trouble of citing <link to Muphry's law>. Yay!"