On Thu, Aug 9, 2012 at 5:59 PM, Andrew Faulds <a...@ajf.me> wrote:
> yield(), so far as the programmer is concerned, might as well be a function.
> It isn't, strictly speaking, but like other function calls, it suspends
> execution of the function until the called function completes.
>
> So I don't think this is a problem.
I definitely can see that yield() is a plausible syntax, but I still
think that the normal yield notation is better suited. Another reason
is the following:
PHP has several constructs with a yield-like syntax. Examples are
"include $file" (and require etc) and "print $string". Both are
keyword expressions, so they are rather similar to yield.
On the other hand there are also other constructs which use the
function notation. Like isset(), empty(), etc.
The main distinction between them is their primary use: Both include
and print are usually used as statements, not as expressions. Writing
$foo = include "bar"; is something you rarely do. So here the
friendlier keyword notation is chosen. isset() and empty() on the
other hand are pretty much always used as expressions (they really
don't make sense as statements). So the function-like syntax is chosen
here, because it causes less ambiguities.
For yield the same applies. Yield will be primarily used as a
statement. The vast majority of cases will just be
yield $someValue;
The expression use is just secondary here. And even there the
value-less yield (the one that does not need parens) is the most
common case:
$data = yield;
The case where you want to both receive and send at the same time is
rather rare (mostly for trampoline patterns or task scheduling).
So I think we should not sacrifice the most common cases for slightly
better syntax in the rare cases.
Also, currently yield looks very similar to return and I think this is
a nice thing as it is similar semantically. yield($foo) would give it
different semantics, imho.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
