Hacker News new | comments | ask | show | jobs | submit login
How to add a new syntactic feature to PHP (nikic.github.com)
210 points by maratd on July 27, 2012 | hide | past | web | favorite | 36 comments

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.

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.

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.

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.

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.

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

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

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.

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.

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


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

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.

I think a person capable of performing this sort of change against PHP is also capable of understanding that implicitly.

> 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.

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.

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

\ 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.

Except :: doesn't always indicate a static class member.


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.

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.

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

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

Very instructive.

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.

The article wasn't really meant as "Patch your own PHP and break compatibility". Rather it was intended as "Contribute new language features to the main PHP distribution" :)

I wouldn't advise anyone to run PHP with patched syntax ^^

I voted your comment up, but I think it would be more effective if you deleted everything before "PHP's main advantage is..." The first part invites a language war. I don't want to see a language war here unless it includes examples of how other languages extend their syntax.

> "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.

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.

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.

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.

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

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.

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.

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

Heroku's uptime.

Looks pretty good from here: https://status.heroku.com/past

Plenty of php based web sites (not web apps, sites) use shared hosting

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact