Hi Sara,
Le 12/05/2016 à 19:02, Sara Golemon a écrit :
On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski <z...@zend.com> wrote:
Whether it's $$ or !# or $0 or any other random symbol doesn't really matter.
Agreed.
Here we have a completely optional syntactic sugar,
that's not nearly as widely useful as OOP or namespaces.
Very few things will be as widely useful as OOP or namespaces, so that
comparison is a bit of a red herring. This construct is useful
anywhere function call nesting pushes you past a readability
threshold. That's not as ubiquitous as OOP as a whole, but it's
pretty widespread. As widespread as fluent call chaining, in fact.
The question is whether the added complexity of a new operator,
a new symbol and the new semantics around them both are
worth the benefit of introducing them.
Agreed. There's a cost to every new token and parser rule on the
compiler side, and there's a cognitive overhead on the script
maintainer side as well. It seems we only disagree in the flexibility
provided by better syntax and the ease of using google,
stack-overflow, and php.net/manual.
IMHO it's not.
And I'll expect you to vote accordingly. No hard feelings. :)
-Sara
Currently, the proposal accepts any expression between '|>' operators,
which requires the '$$' placeholder (as '|> $$ + 2 |>' would be valid).
If we restrict usage to function calls, we can quite easily get rid of
the $$ by associating to each function the position where the lhs must
be inserted when used as a 'piped function call'. This position would be
0 (first arg) for most existing functions and 2, for instance, for
str_replace(). Getting rid of the $$ would resolve most issues about
parameter order in the existing library, which is probably the biggest
PHP sadness.
My question, before I write a detailed proposal for this, is : do you
want to keep the possiblility to use *any* expression between pipe
operators, or would it be acceptable to restrict this to function calls?
Note that it would also disambiguate 'piped assignments' like '|> $var
|>' (assigning to an intermediate or final variable).
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
