
How to add a new syntactic feature to PHP - maratd
http://nikic.github.com/2012/07/27/How-to-add-new-syntactic-features-to-PHP.html
======
randomdrake
Beyond the excellent explanation of how to do this, the section on the "Life
of a PHP Script" is absolutely wonderful.

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.

------
pbiggar
I've spent a lot of time in the PHP internals, and this seems like an
excellent and comprehensive guide.

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.

~~~
RobAley
I think that it's actually one of the benefits of the PHP development process,
and one of the reasons for PHPs popularity.

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.

~~~
pbiggar
I'm not saying it's a focus on the syntax. I'm saying it's a lack of attention
to anything else.

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.

~~~
RobAley
I actually think that PHPs syntax is good (in the main), it seems to fit with
the way my thought process works and I'm incredibly efficient with it. It's
different from many other languages syntax, it's verbose in places and not as
"intellectually pleasing" as some, but for getting work done (at least for
developers like me) its hard to beat. It's not that I haven't been exposed to
other languages, I did a degree in computer science and have worked for 12
years in the industry (formally commercial, latterly academic) using assorted
different languages. But since I discovered it, to this day I still prefer
PHP, in large part due to the syntax.

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.

------
dkhenry
This is the kind of documentation PHP _should_ have had all along. Kudos for
going into such depth.

~~~
Spoom
To be fair, most people going to php.net aren't looking to hack the PHP core.

~~~
dkhenry
yeah but anyone who is has nothing even close to this to look at. Essentially
you have the source code and a few undocumented examples to figure out how to
extend the language.

~~~
jasonlotito
There has been numerous articles like that posted over the years, even
recently, that talk about adding extensions and working with PHP internals.
This is an excellent article, but you have much more than just the source code
and a few undocumented examples.

~~~
dkhenry
I can go search Blogs and articles ,but the official documentation is blank.
You don't have to take my word for it.

<http://php.net/manual/en/internals2.apiref.php>

------
starzero
I recommend Extending and Embedding PHP by Sara Golemon as a good starting
point to PHP internals.

------
davidarkemp2
nice post, but it misses out the bit about documenting the change, making sure
that your distribution doesn't suddenly nuke your changes when it does an
upgrade, finding programmers who can work on your codebase given your
customisation of php...

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.

~~~
maratd
> or forking php - something that can't be done likely

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.

~~~
ihsw
PHP is not on Github, the project on Github is simply a mirror.

<http://git.php.net/> <https://github.com/php/php-src>

EDIT: They are receptive pull requests, though.

------
zbowling
I wonder if someone could take this and fix that silly namespace character.

~~~
snorkel
\ was an odd choice, unfortunately reminiscent of MSDOS, but I have to admit
that it does help when reading code that a path with \ signals that this is a
namespace path where :: is a static class member.

~~~
mgkimsal
Except :: doesn't _always_ indicate a static class member.

parent::foo();

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.

~~~
encoderer
The grandparent has the right sentiment but the wrong language. When you see
:: you know you're addressing a specific class and not a namespace.

And since PHP doesn't have any concept of a class-instance there's nothing
mucking that up.

------
snorkel
Excellent. I wish there was a similar tutorial for adding language features
SpiderMonkey.

------
gedrap
And the author is 17 years old. I'm well impressed.

------
hk__2
Very instructive.

------
pmb
Cool, but seems unwise.

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.

~~~
pbiggar
> "PHP's main advantage is ..."

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.

~~~
pmb
Those are what its advantages were. Now its main advantages seem to be: (1)
Omnipresence and (2) Easy to migrate from a static site (I missed that one in
my prior comment, and it's an important one - thanks!). All the others are
relative to the environment of its birth, rather than today's environment.

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.

~~~
pbiggar
Indeed, fair point. But I think PHP's omnipresence is no longer the great
advantage it once was. Its so easy to learn Ruby and deploy to heroku.

~~~
stephenr
One hosting site that's backed by another hosting company that has a history
of huge, extended outages does not make ruby or rails "omnipresent"

I seriously question anyone who uses heroku for production anything.

~~~
pbiggar
Right, but you're not using shared hosting for production either.

~~~
jasonlotito
I have sites hosting on shared hosting providers that have better uptime then
Heroku.

They aren't big sites. Hell, they are little sites, with barely a trickle of
traffic. But that traffic results in real, paying customers.

~~~
pbiggar
I don't know where this idea of heroku having poor uptime is from. Heroku has
excellent uptime - even during the ec2 outage most sites had very little
actual downtime.

~~~
jasonlotito
> I don't know where this idea of heroku having poor uptime is from.

Heroku's uptime.

~~~
pbiggar
Looks pretty good from here: <https://status.heroku.com/past>

