On 28/09/2017 20:07, Levi Morrison wrote:
The brace style is concise, nicely delimits the
expression, and seems the clearest for me to read because the symbols don't
dominate.
This is something that I tried to push for in previous discussions -
I've never liked the syntaxes where the expression floats away from the
operator, and you have to work out where it ends. The counter-argument I
got was that some people actually like writing things like this,
although I'm not entirely clear why:
fn($x) => fn($y) => in_array($x, $y)
Which brings us to the question of how we might generalise the {} syntax
for more complex situations. Clearly, we can't just nest them if the
first parameter is always called $0:
{ { in_array($0, $0) } } #WAT?
Obviously named variables are kind of useful anyway, so maybe $0 could
be the default, but allow them to be specified:
// Simple definition
{ $0 . ' world' }
==
{ $greeting => $greeting . ' world' )
// Nested definitions
{ $x => { in_array($x, $0) } }
==
{ $x => { $y => in_array($x, $y) } }
// 2-parameter function
{ $x, $y => in_array($x, $y) }
> My impression from the community is that the pipe operator is
desirable but
> not if it encourages string or array callables.
Yeah, my first thought on this thread that I liked this version of the
proposal significantly less than the previous one, because I always
liked the idea of this being a programming style, with the RHS being a
statement to be rewritten. So you could write $input |> $foo = $$ |>
echo $$ |> return $$ ...
But with a suitable way of creating a callable to pass to it, I could
live with it.
What if the syntax for taking a reference to function was just a special
case of the partial application / lambda syntax? At risk of turning into
Perl, we could use "$..." to mean "copy in all the parameters":
$foo = { in_array($...) };
This would be logically equivalent to:
$foo = function(...$x) { return in_array(...$x); }
But the compiler could actually optimise it as something more like
Closure::fromCallable('in_array')
Just throwing some thoughts out there to see if any of them stick...
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
