This is, quite frankly, beautiful.
Huge kudos to Nikita Popov for providing such a great illustration of how PHP works, internally, from the tokenization process, to the parsing, and finally the execution.
I have always been curious about the process and have read other documentation that provides some insight but none of it has come close to this.
Even if you aren't interested in PHP or providing features to PHP, you should give this a read to understand how programming languages like PHP work.
However, I think that the title and the concept behind the post demonstrates how PHP got the way it is. Note how it's focussed on the syntax - this isn't a guide to ensuring that your feature has good semantics, or that it works well with existing features, or how to avoid creating new syntax by extending existing hook points in the language.
Nearly every PHP internals discussion about creating a new language feature has started and ended with "what will the syntax be" (sometimes even with a _vote_ about it!). Some more emphasis on the other aspects of language design would be welcome.
The focus on syntax is actually a focus on it's users, the programmers (or at least the subset of programmers that PHP is aimed at). The syntax in PHP is what lets us simply Get Stuff Done, and so the top-down approach to development is suited to the language.
Sure, it has some trade-offs in terms of things like performance and future (internal) maintenance, but for most developers using PHP on a day-to-day basis those trade-offs are completely worth it.
Language is much more than syntax, and that main reason people leave PHP is because the various parts of the language do not work well together.
If this were truly a focus on the syntax, than PHP would have good syntax. But it's not, its a shallow "lets hack whatever works, damn the consequences" attitude. Those work in early stages of a project, when you're prototyping, to move it forward. I don't think PHP is in that stage.
And I think it is largely untrue to say that there is a lack of attention to other aspects of the language, particularly recently. The focus on performance increases, changes to the internals to implement new features (albeit often via a syntax-first approach!) and the current discussions around the future of PHP (PHP6 and Zend Engine 3) which aren't by any measure solely about syntax show that there is a wider appreciation of different aspects of the language.
PHP has a different focus from many languages, and that is why some people leave (or don't start in the first place) and find a language that is better suited for them. But for a large number of us it is a useful hammer that hits our particular nails right on the head, and that's not a bad thing.
It's a useful post, but I'd like a but more warning that you really don't want to do this unless your proposing on either contributing this back into the core codebase, or forking php - something that can't be done likely. It reads a bit too much like this is something everyone should be doing.
Why? PHP is on Github now. Merging changes from upstream should be relatively trivial as long as you don't get too excited about adding/subtracting stuff.
EDIT: They are receptive pull requests, though.
The :: is not indicating that the call to the parent be made statically. $this is a reserved variable in classes - $parent or $super should have been as well.
And since PHP doesn't have any concept of a class-instance there's nothing mucking that up.
If you are smart enough to do this to PHP, then you are hopefully smart enough to know you should probably not be writing your large system in PHP. There are many better base languages, as opposed to one which has the consistency of perl combined with the string handling power of C (a mild exaggeration, but not by as much as I wish it were). PHP's main advantage is that it is installed everywhere and just works. This breaks that, and therefore renders PHP's main advantage moot.
I wouldn't advise anyone to run PHP with patched syntax ^^
I wrote out a list of PHP's main advantages a while ago (http://news.ycombinator.com/item?id=3347956), but I don't think there's just one.
Today we have choices other than Perl, C, and PHP - and many of those choices are free and Free and have great docs and large healthy communities and have languages and libraries with a better design. When people get good enough at programming to understand why global variables are bad, they should generally not be choosing PHP for new projects unless they need one of the above two features.
I seriously question anyone who uses heroku for production anything.
They aren't big sites. Hell, they are little sites, with barely a trickle of traffic. But that traffic results in real, paying customers.