PHP Short Closure syntax
and symbol choice
RFC voting has begun for Short Closure syntax in PHP meaning that if it passes we’ll end up with another weird and in my humble opinion far from optimal syntax introduced in PHP.
The RFC introduces a language change so it means it needs a 2/3 vote majority in order to pass. At the moment of writing we are at 12 “yes” and 6 “no” votes which means it’ll pass and gets introduced in PHP 7.1
And that is a bad thing. Why? Let me explain.
What is Short Closure Syntax?
Short Closure Syntax (aka Lambda Expressions) is a feature that’s present in multiple other popular languages like javascript and ruby? It allows us to write closures (introduced in php 5.3) in a shorter and less verbose way.
I can see where it’s coming from, Short Closure Syntax clearly has it’s advantages because in most cases you write a Closure over multiple lines as you would define a function. This short syntax allows us to keep the code nice and clean and not spread function calls that contain a Closure over multiple lines.
The choice of operator symbol
But lets discuss the choice of operator “~>”. Yes you read that right … it’s a “tilde” followed by a “greater than” sign.
The symbol ~> was chosen as it is a mnemonic device to help programmers understand that the variable is being brought to a function. It is also unambiguous as it has not been used elsewhere in PHP
~ https://wiki.php.net/rfc/short_closures#symbol_choice
What on earth is a mnemonic device? Mnemonics are a technique to present information to humans in a way that allows us to memorize it easier. All good and well but what about readability?
I personally dislike the choice of operator because the difference with the object operator (->) is minimal and can easily be overlooked. And if you want to convey “bringing a variable to a function” there are way beter options.
Other language implementations
How do other languages implement lambda’s and their short syntax? Let’s see.
I personally like the python version the most. Simply because there is no room left for mistaking the operator with another operator.
In all honesty, the python version isn’t a real “short” lambda version, it’s the default lambda implementation in Python, but it serves it’s purpose very well and leaves no room for misinterpretation.
Ruby and Coffeescript both use a variation of the same syntax using the arrow notation.
What about the Hacklang syntax?
The hacklang version is runner up in this case. According to the RFC they were actually considering using this but decided against it after Sara Golemon (of HHVM fame) advised against it.
Well played Sara. Hacklang has superior syntax over PHP already and now RFC’s for the PHP language itself are being influenced by the fact that Hacklang is protecting it’s own syntax. This is a clear win for Hacklang since PHP is settling for a less optimal solution so Hacklang can keep using the beter version of the syntax.
Other shortcomings
Apart of the weird choice of operator this RFC has more things going against it.
“No type hint or return type support” for example. These could not be implemented due to parser problems.
And apparently all variables passed into the Short Closure Syntax will be bound by value, not reference. There is no alternative for the “use” statement in the current Closure syntax. For a Short Closure Syntax this seems a weird choice.
If I were king …
I’m not a fan of the RFC in it’s current state. If I had my say I would advice using the python syntax and introduce a new language construct instead of inventing weird and confusing new operators.
The most notable trend I must say is that for this RFC the PHP core devs went out of it’s way to make sure Hacklang could keep using their superior syntax. An obvious choice from hacklang’s perspective but weird from PHP’s.
I’m not against Short Closure Syntax, making PHP easier to use and less verbose is a good thing in most cases. What I am against is introducing unnecessary new syntax and half implemented features that don’t fully solve the problem they claim to solve.
Header photo by Aldo Lammel
