Den 2015-09-03 kl. 00:48, skrev Rowan Collins:
On 02/09/2015 22:49, Sara Golemon wrote:
Beautiful code is code that is easier to
maintain, and code that is easier to maintain is often more secure and
reliable.
I think this is an important point. Obviously, "beauty" is subjective:
some people will find very verbose, English-like code easier to read;
others might try to squeeze as much information into one screenful as
possible, so they can see the whole program at a glance.
At one extreme, SQL has mandatory words like the "AS" in "CAST(x AS
int)" just to "look more like English"; at the other, APL has symbols
all of its own with their own Unicode code points. Most languages aim
for some compromise in between.
So I would like to put forward for consideration these amendments to
the proposal, in the spirit of compromise (in no particular order;
numbers are just for reference in future discussion):
Amendment 1. Only allow the single-expression form of the short
syntax; full function bodies must be declared with the existing
function(){ ... } syntax. This gives a clearer distinction between how
the two syntaxes can be used.
Amendment 2. Make the ~> operator non-associative, so that lambdas
returning lambdas would need an extra pair of brackets making the
nesting explicit. To take one of Anthony's examples:
function partial(callable $cb) {
return $left ~> ( $right ~> $cb($left, $right) );
}
It's now at least clearer that there are two different anonymous
functions here, even if it's not entirely clear what they're trying to
achieve...
Amendment 3. Make the parentheses around the argument list mandatory
so that (if Amendment 1 is also adopted) there is only a single
variant of the syntax, namely "( param list ) ~> expression".
Amendment 4. Consider a syntax involving an explicit "use". This one
requires a bit more exploration, but maybe something like:
( $a use $b ) ~> $a + $b
or:
( $a ) use ( $b ) ~> $a + $b
Perhaps there are other thoughts along these lines that could move the
proposal beyond a simple love/hate debate.
Regards,
Any plans to incorporate any of the amendments above in the RFC?
Personally I favour amendment 3. One of your examples would be:
functionreduce(callable $fn){
return($initial)~>($input)~>{
$accumulator=$initial;
foreach($inputas$value){
$accumulator=$fn($accumulator,$value);
}
return$accumulator;};
}
Or maybe I'm just overly familiar having function arguments
within parenthesis ;)
Regards, //Björn Larsson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
