It’s the double colon operator :: (see list of parser tokens).
It’s the double colon operator :: (see list of parser tokens).
[PHP] T_PAAMAYIM_NEKUDOTAYIM, a tale of nerd gridlock
Moodle in English: Double Colon in Hebrew Paamayim Nekudotayim and PHP help please | Moodle.org
php - What does this mean? "Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM" - Stack Overflow
history - What's the meaning of the PHP token name T_PAAMAYIM_NEKUDOTAYIM? - Stack Overflow
Today's hobby drama is about the infamous T_PAAMAYIM_NEKUDOTAYIM error message in the PHP software. It happened in 2010, inside the php-internals mailing list. I wasn't there myself so this is a third-hand account, based on a fun blog post that I read recently. I encourage the programmers in the audience to also read that blog post in addition to my summary of the story.
What is PHP
In 1995, Rasmus Lerdorf invented the PHP programming language to help create his personal website. Hence the name, which originally meant "Personal Home Page". PHP would become fantastically popular for web development, being used to implement many of the Internet's most visited websites, including Wikipedia and Facebook.
One of the reasons for this popularity is that PHP is free to use. Both in the "free as in beer" sense (programmers don't need to pay to use PHP) and in the "free as in freedom" sense (programmers are allowed to share the PHP software with others, which resulted in it being widely available).
PHP's open source nature is reflected in it's development culture. Like many open source projects it is not developed behind closed doors inside some company. It is developed in the open by a mix of volunteers and paid consultants. These developers communicate with each other mostly via email, in the "php-internals" mailing list.
Today's story is a classic example of mailing list drama. Mailing lists can have a tendency to attract the sort of hardcore fans that are willing to spend a lot of time discussing about obscure corners of the programming language.
The casus belli
In 1997, a team of programmers from Israel rewrote the PHP engine. Their improved version was better and faster so it eventually became the official version of PHP that everyone used. One of the quirks about this rewrite is that they used Hebrew names for several parts of the engine. Normally, these internal names don't matter but there was one exception: the PHP parser.
The job of the parser is to make sense of all the symbols that appear in a PHP program. One of the quirks of PHP's parser was that its error messages would refer to the internal name for the symbols. For example, if a PHP programmer accidentally added an extra += to the program they might receive an error message about a T_PLUS_EQUAL symbol. Some of the error messages were more cryptic; a PHP programmer might have needed to google the error message to find out that T_SL refers to <<, the "shift left" symbol.
But the king of all of these error messages was without a doubt the :: symbol. PHP programmers who accidentally put a :: in the wrong place would be greeted with
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in blah.php on line 1
What's a T_PAAMAYIM_NEKUDOTAYIM? It turns out that it means "double colon" in Hebrew, but how many people would be able to guess that? This error message stumped countless PHP newcomers and became one of the most frequently asked PHP questions. In the StackOverflow Q&A website, the question about T_PAAMAYIM_NEKUDOTAYIM has over 500 upvotes. There used to be a wikipedia article about it. The PHP Sadness website, which chronicles PHP quirks and oddities, used T_PAAMAYIM_NEKUDOTAYIM as their founding example, the very first oddity that they added to their list.
The Drama
Around 2010, an admin for a popular PHP Q&A forum had enough of this. He wrote the following email to the php-internals mailing list:
WTF is T_PAAMAYIM_NEKUDOTAYIM?
This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don’t have to hear about it constantly?
Those that disagree don’t do enough PHP support to know how often it is asked. it’s worth it.
This exasperated email might not have been the most persuasive way to start the discussion. But I can empathize with him. As the admin of one of the most popular Q&A forums, he must have been receiving NEKUDOTAYIM questions all the time. Anyway, the denizens of the php-internals mailing list were not moved by the pleas for change. A PHP developer throws the first stone:
Someone disagreeing with your request to change something does not correlate to their doing “enough PHP support.” There are many reasons to disagree with a change request, no matter how much any one person thinks of it as a necessity or an improvement.
Another user in the mailing list joined in with the classic "if it ain't broken, don't fix it" argument, ignoring the fact that the subject in question was in fact broken.
Why should this be changed? Is it broken? Is it something that 1 second on google can’t answer? If somebody is advanced enough to be using classes (I think about the only time you would use a double colon) then they should know what it means.
PHP's inventor Rasmus Lerdorf lends support to the conservatives, making an appeal to multiculturalism.
There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel, and it is a good reminder that there are a lot of other languages in the world. People whose first language is not English, myself included, are forced to work with unfamiliar terms every day. I wouldn’t mind having a few more non-English identifiers in PHP actually.
Well, and a third reason, I like it.
Some people did agree with original proposal, however. Another PHP user pleaded the community to not get stuck in a "nerd gridlock".
It’s amazing to me this has become such a long discussion. The facts are simple:
People don’t ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM.
They do so because it looks like gibberish to them, so it looks unlikely to be a common thing you can Google, nor it gives something recognizable to start with
Yes, to all who are not sure, more people know English than Hebrew.
Yes, we all acknowledge it’s an easter egg joke that refers to the creators of PHP. But that particular joke has outworn its welcome in the community after repeatedly causing support issues.
T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won’t be an epic change. Let’s do it as a proof that we’re not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement.
But that wasn't enough to convince the conservative faction.
Come on people, what exactly is the problem with a once-in-a-lifetime investment of 5 seconds of your time to google some stupid error message. Something you, as a developer, spend your life doing.
Please, stop complaining about a minor (yes, it is minor, use the fricking search engine!) annoyance and accept php’s heritage.
And please understand, I do get where all the opponents are coming from, it is an unnecessary complicated error message (I agree that the language argument is a moot point, in the world of internet and programming in particular, English is the standard), but you google it once in your life and then you ‘forget’ about it. And if you can’t remember the meaning of something like that, I hardly doubt you’d be a decent programmer anyway.
The admin of the Q&A forum returns, even more exasperated than before.
It’s the same argument everyone else is giving, and really it all comes down to this.:
Nostalgia is valued over clarity and consistency.
Do you guys REALLY want to claim that?
The answer in the php-internals mailing list appears to be "yes". The user who made the first "it ain't broken" argument sends another email. He argues that changing the error message would not fix the root problem of PHP users not knowing Hebrew:
If it ain’t broken don’t fix it.
Change for the sake of it is a bad thing. It does things like introduce bugs etc.
Q1) is it broken? Q2) if yes exactly what is broken Q3) does the proposes fix solve the root cause?
I’m not sure changing the token name is the correct fix to people not knowing what the error means.
He also argues that those who are unsatisfied with the current error message are free to change it on their own webservers. This is despite the fact that most newcomers wouldn't be using a patched webserver.
Are you supporting users who you provide a shared hosting embodiment too, and do you control binary installations on the environments? If so then possibly patching source for you installs maybe the easiest and quickest solution. If we knew the nature of your support requirements, then we could possibly suggest a better solution or be won round. (although internals isn’t the place for that really)
A hero emerges
Finally, a light emerges from the heavens. One member of the mailing list points out that fixing the error message would be extremely simple:
Instead of renaming the token, I prefer to associate a literal string to each token, to have a legible error message, without the T_ being shown.
For example, we could use in the Bison grammar file: %token T_PAAMAYIM_NEKUDOTAYIM ”::”
All they need to do is find this line in the engine
%token T_PAAMAYIM_NEKUDOTAYIM
and add an user-facing name at the end
%token T_PAAMAYIM_NEKUDOTAYIM ”::”
That's it! This suggestion was kryptonite against the conservative faction. It's hard to argue that the change will cause bugs when it's so trivial to implement. The conservatives scatter, like a bunch of dementors struck by a patronus charm.
PHP leader Rasmus Lerdorf accepts the suggestion. He says that this "token name" feature wasn't available in 1997 when the parser was originally written, but that there would be no problem in using it now.
Years and years ago that was the intent. I didn’t think there was a clean way to do that in yacc though.
The next release of PHP, version 5.4, updated the error messages.
A concession to the conservatives
After admitting defeat, the conservatives made one last demand. They argued that entirely removing the Hebrew name might "confuse users" so they insisted that it should remain as part of the message. The error message in PHP 5.4 went out of the way to still say the internal name, between parenthesis.
Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM) in blah.php on line 1
This required a more convoluted implementation:
%token T_PAAMAYIM_NEKUDOTAYIM ”:: (T_PAAMAYIM_NEKUDOTAYIM)”
T_PAAMAYIM_NEKUDOTAYIM remained a part of PHP error messages for another 10 years. It was finally removed for good in PHP 8.0, released in late 2020.
T_PAAMAYIM_NEKUDOTAYIM is the double colon scope resolution thingy PHP uses - ::
Quick glance at your code, I think this line:
return $cnf::getConfig($key);
should be
return $cnf->getConfig($key);
The first is the way to call a method statically - this code would be valid if $cnf contained a string that was also a valid class. The -> syntax is for calling a method on an instance of a class/object.
Just my two cents for future visitors who have this problem.
This is the correct syntax for PHP 5.3, for example if you call static method from the class name:
MyClassName::getConfig($key);
If you previously assign the ClassName to the $cnf variable, you can call the static method from it (we are talking about PHP 5.3):
$cnf = MyClassName;
$cnf::getConfig($key);
However, this sintax doesn't work on PHP 5.2 or lower, and you need to use the following:
$cnf = MyClassName;
call_user_func(array($cnf, "getConfig", $key, ...otherposibleadditionalparameters... ));
Hope this helps people having this error in 5.2 version (don't know if this was openfrog's version).
From the PHP docs:
Paamayim Nekudotayim would, at first, seem like a strange choice for naming a double-colon. However, while writing the Zend Engine 0.5 (which powers PHP 3), that's what the Zend team decided to call it. It actually does mean double-colon - in Hebrew!
It's the scope resolution operator.