[PHP-DEV] Generators in PHP

>
> Suggestion:
>
> For a generator, rename the keyword "function" to ... "generator" or
> something like that. Example:
> generator hugo()
> {
> yield ...
> }
>
> As Nikita pointed out, having a T_GENERATOR token will cause side-effect
problems from namespace collisions. This is a concern any time you add a
keyword to the PHP parser.


> Fact: yield/generators is more or less complicated, this shouldn't be
> changed - it's a proven concept.
>
Speaking of parse errors, I'm having trouble parsing this line. I *think*
you're saying that generators are just complex things and that's the way it
should be. I... guess I agree, though I have a lower opinion on the
complexity of generators. Seem like a fairly straightforward concept to
me. They are certainly proven concepts.

Fact: yield makes functions some kind of "different".
>
Yes, they turn normal functions into continuation functions (functions
which can be exited and reentered dynamically).


> Fact: It doesn't matter how it is implemented in other languages,
> because we talk about PHP and not other languages.
>
Disagree somewhat. Part of PHP's ease-of-use it it's similarity to other
languages so that a developer working on C or Perl or Java or
what-have-you, can look at PHP code for the first time and have a pretty
good idea of what's going on. Mirroring existing implementations should
certainly be a consideration for that purpose. Not the end-all decider,
but a consideration.


> Fact: This is also good style in general: Call the things what they are.
>
I'll grant this point has merit, however it has two counter-arguments. (1)
T_GENERATOR naming conflict mentioned above. (2) Generators *are* still
functions, so the name "function" isn't a misnomer. They're just a special
type of function similar to how methods are special types of functions, but
we still label them as "function".


> Fact: as PHP-developer we must try to avoid making things more
> complicated, because this is one of the best features of PHP.
>
Agreed. And a generator is far less complex than a full iterator
implementation. Further, continuation functionality is far less complex
than building in loop counting logic to an iterator's next() method.


> Fact: it's easy to implement a new keyword into PHP for that case
>
False. See above.


> Experience: Most PHP programmers will have problems to understand
> generators because it is a function that generates an iterator...

something magic <eyesroll> they never heard of before.
>
Fact: PHP's manual is the best in the industry. PHP developers know this.
PHP developers are smarter than you give them credit for.


> Experience: generators/yield can't be explained on one page. Much
> programmers will never ever read so much docs. :)
>
The core of what a generator is can be explained in a single paragraph with
a few examples - Just like nearly every page in the PHP manual. If we
can't give PHP developers that much credit, then we should shut the project
down now.


> Experience: good features are self-explaining. A function which
> returns an iterator because of a simple word in it's body is not.

A developer who's never seen the yield keyword before need only learn what
it is once. http://php.net/yield Problem (to be) solved.


> Experience: They will make stupid mistakes, because they mix yield
> function with normal functions.
>
And the compiler will slap them for it.


> Experience: They will make stupid mistakes, because they will look for
> "return" instead for "yield".
>
And they won't find it, but hey look, what's this yield thing, I wonder
what that does: http://php.net/yield


> Experience: Not using the same name will remove a little bit pressure
> from "busy" programmers
>
Developers who work with other people's code (and that's who you're talking
about) routinely have to spend time understanding the purpose of a given
function. To assume that one can pretend to understand a function without
having seen and questioned an unfamiliar keyword like "yield" is ridiculous
from the outset.

If this hypothetical developer wants to understand the function, they'll
see it's got yield and learn that's what makes it a generator. If they
don't want to understand the function, then putting up a big sign isn't
going to help the matter whatsoever.


> Experience: The current concept dosn't "feel right" for me. I like to
> listen to my belly in those questions, because he is in most cases
> right. With the change I suggested he stops grumbling.
>
Fair enough. Unfortunately, for the reasons stated above, it's just not
that simple.

Hi!

> Speaking of parse errors, I'm having trouble parsing this line. I *think*
> you're saying that generators are just complex things and that's the way it
> should be. I... guess I agree, though I have a lower opinion on the
> complexity of generators. Seem like a fairly straightforward concept to
> me. They are certainly proven concepts.

They're not that complex. They are basically a syntax sugar around
iterators, and we already have tons of iterators which are widely used.
Actually, it's easier than iterator since you have to implement just one
method, not five of them.

Of course, it's not a beginner's feature - but we have now many features
which require some understanding of the language - like magics,
anonymous functions, etc. It doesn't by itself make it inappropriate. If
we can make it work in a way that won't be confusing and illogical for
people knowing how iterators work, then I think it's OK.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Sara Golemon wrote:
> Fact: yield makes functions some kind of "different".
>> >
> Yes, they turn normal functions into continuation functions (functions
> which can be exited and reentered dynamically).

But WHY would you not simply put the function that is handling the returned data
in place of the yield?
Why do you want to keep exiting and re-entering the 'do loop' when the data can
simply be forwarded direct to a function to handle it?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> -----Original Message-----
> From: Nikita Popov [mailto:[email protected]]
> Sent: 22 July 2012 16:53
> To: Jared Williams
> Cc: Nikita Popov; PHP internals
> Subject: Re: [PHP-DEV] Re: Generators in PHP
>
> On Sat, Jul 21, 2012 at 6:31 PM, Jared Williams
> <[email protected]> wrote:
> > Can't yield a reference to an array item directly.
> >
> > Eg.
> >
> > function &map(array &$row)
> > {
> > yield $row[0];
> > }
>
> Thanks, this is fixed now.
>
> > Also seems to be a problem with iterating
> >
> > foreach(map($row) as &$value)
> >
> > cannot be done without a fatal error
> >
> > $i = map($row);
> > foreach($i as &$value)
> >
> > however works.
>
> This was an old foreach restriction that never really made
> sense and makes even less sense once generators are in. So I
> dropped it. Now everything can be iterated by-reference.
>
> > Seems relatively easy to trigger a infinite loop atm.
> >
> > Typo'd a SQL table name which caused an exception within
> PDO inside a
> > generator function, which then caused an infinite loop.
>
> I forgot to rethrow the exception in the foreach scope.
> Should be fixed now.
>
> Thanks for your feedback!

No problem.

Though here is seemingly another problem, though it could be within
spl's MultipleIterator()

function a()
{
yield 'a';
yield 'aa';
}

function b()
{
yield 'b';
yield 'bb';
}

$m = new MultipleIterator();
$m->attachIterator(a());
$m->attachIterator(b());
foreach($m as $v)
{
list($a, $b) = $v;
var_dump($a, $b);
}

causes a seg fault, whereas the vanilla array version

$m = new MultipleIterator();
$m->attachIterator(new ArrayIterator(['a', 'aa']));
$m->attachIterator(new ArrayIterator(['b', 'bb']));
foreach($m as $v)
{
list($a, $b) = $v;
var_dump($a, $b);
}

works fine.

Jared



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/25 Nikita Popov <[email protected]>:
> particular with namespaced code). So if you have some kind of
> Code\Generator class, you're screwed.
> Keywords don't grow on trees, you know ;)

Hm. Ok, thats a problem.
Oh, man, do I really have to find a good keyword myself? Maybe we
should use a password-generator. :)
Seriously, how's about

yielder hugo() { ... yield ...}

Feels right, but my native language is not english, so I risk to make
me a fool. I think that also names what it really is: A yielder yields
something. In this case: An iterator yielder yields an iteration. I
think I would like that.
And the word is per sure not common. :)
Ahmm, if you don't like it, would you be so kind to make a suggestion? TNX

> Also I'd like to point out that being similar to other languages is in
> the general case a *good* thing. So if you say "It doesn't matter how

In general I agree. For PHP I do not. This case is a little bit
different, because the targets are self-explaining and simplicity.

> Deviating from the
> "standard" generator implementation without having good reasons seems
> rather pointless to me.

But I gave good other reasons. :)



Conclusion:
==========

Fact: generator is not a good keyword, because too common.

Answer: I made a new sugestion with the keyword "yielder".

Fact: in general it's a good idea to implement features, like in other
languages.

A: Correct, but

Fact: PHP has different architectural targets which doesn't mean to
make everything different, but ...
Experience: in this case I'm sure, it's not the best way to make it
like any other language.
Experience: If you have enough reasons to make things different, don't
look too much how others are doing.
Experience: Most PHP-programmers are not so experienced like most
programmers in other languages.
(Can't be proven, but I would bet for it.)

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 26 ביול 2012, at 01:22, Alex Aulbach <[email protected]> wrote:

> 2012/7/25 Nikita Popov <[email protected]>:
>> particular with namespaced code). So if you have some kind of
>> Code\Generator class, you're screwed.
>> Keywords don't grow on trees, you know ;)
>
> Hm. Ok, thats a problem.
> Oh, man, do I really have to find a good keyword myself? Maybe we
> should use a password-generator. :)
> Seriously, how's about
>
> yielder hugo() { ... yield ...}
>
> Feels right, but my native language is not english, so I risk to make
> me a fool. I think that also names what it really is: A yielder yields
> something. In this case: An iterator yielder yields an iteration. I
> think I would like that.
> And the word is per sure not common. :)
> Ahmm, if you don't like it, would you be so kind to make a suggestion? TNX
>
>> Also I'd like to point out that being similar to other languages is in
>> the general case a *good* thing. So if you say "It doesn't matter how
>
> In general I agree. For PHP I do not. This case is a little bit
> different, because the targets are self-explaining and simplicity.
>
>> Deviating from the
>> "standard" generator implementation without having good reasons seems
>> rather pointless to me.
>
> But I gave good other reasons. :)
>
>
>
> Conclusion:
> ==========
>
> Fact: generator is not a good keyword, because too common.
>
> Answer: I made a new sugestion with the keyword "yielder".
>
> Fact: in general it's a good idea to implement features, like in other
> languages.
>
> A: Correct, but
>
> Fact: PHP has different architectural targets which doesn't mean to
> make everything different, but ...
> Experience: in this case I'm sure, it's not the best way to make it
> like any other language.
> Experience: If you have enough reasons to make things different, don't
> look too much how others are doing.
> Experience: Most PHP-programmers are not so experienced like most
> programmers in other languages.
> (Can't be proven, but I would bet for it.)
>
> --
> Alex Aulbach
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Wow, I wasn't near my computer for the last day and I see that the conversation really grew ;)
"yielder" sounds quite weird don't you think (but my native language is not English too.. so don't blame me at english stupid conclusions!)

> Fact: generator is not a good keyword, because too common.
I can't see the connection... people relate the generator keyword to the iterators so what's the problem using it?

what about using the "iterator" name as generators keyword? because it does return iterators...

iterator foo() { ... yield $bar; ... } sounds OK for me... and got a meaning too.
though it can confuse some people with the original iterators...

BTW: I still don't think that the generators need a unique word and I suggest using functions, but I didn't read al the mails chain, so I assume that I'll find there the answer.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/25 Sara Golemon <[email protected]>:
>> Fact: yield/generators is more or less complicated, this shouldn't be
>> changed - it's a proven concept.
>
> Speaking of parse errors, I'm having trouble parsing this line. I *think*
> you're saying that generators are just complex things and that's the way it
> should be. I... guess I agree, though I have a lower opinion on the
> complexity of generators. Seem like a fairly straightforward concept to me.
> They are certainly proven concepts.

I'm willing to say "ok, there we have a new concept, let's put it into
PHP". So I'm willing to support this - under some circumstances.
You say, na, it's not so proven.
Maybe, this can't be proven, but that's why I'm doing this discussion. :)
In the end we mean the same, but different aspects.

>> Fact: It doesn't matter how it is implemented in other languages,
>> because we talk about PHP and not other languages.
>
> Disagree somewhat. Part of PHP's ease-of-use it it's similarity to other
> languages so that a developer working on C or Perl or Java or what-have-you,
> can look at PHP code for the first time and have a pretty good idea of
> what's going on. Mirroring existing implementations should certainly be a
> consideration for that purpose. Not the end-all decider, but a
> consideration.

See my last suggestion (yielder instead of generator). If my english
is not too poor, I would say, that every C or Perl developer etc. will
understand what is meant. I think the change is so small, that anybody
who knows the concept will understand.

>> Fact: This is also good style in general: Call the things what they are.
>
> I'll grant this point has merit, however it has two counter-arguments. (1)
> T_GENERATOR naming conflict mentioned above. (2) Generators *are* still
> functions, so the name "function" isn't a misnomer. They're just a special
> type of function similar to how methods are special types of functions, but
> we still label them as "function".

For (1) see new suggestion, for (2) I would say this is not logical.
First you say it's different (I removed that quote), now you say it's
still a function (=not different). Can we agree with: If they're
different renaming is a good style. If not, we don't need to rename
it.

>> Fact: as PHP-developer we must try to avoid making things more
>> complicated, because this is one of the best features of PHP.
>
> Agreed. And a generator is far less complex than a full iterator
> implementation. Further, continuation functionality is far less complex
> than building in loop counting logic to an iterator's next() method.

I never argued against it. I argue against how it is implemented into PHP.

>> Experience: Most PHP programmers will have problems to understand
>> generators because it is a function that generates an iterator...
>>
>> something magic <eyesroll> they never heard of before.
>
> Fact: PHP's manual is the best in the industry. PHP developers know this.
> PHP developers are smarter than you give them credit for.

The best doc is senseless, if you don't have time to read it.
I don't think they're dumb. But the mass of them is in average not so
experienced as the mass of other PL, because there is more mass.

>> Experience: generators/yield can't be explained on one page. Much
>> programmers will never ever read so much docs. :)
>
> The core of what a generator is can be explained in a single paragraph with
> a few examples - Just like nearly every page in the PHP manual. If we can't
> give PHP developers that much credit, then we should shut the project down
> now.

It's my experience. And can I tell you: Most times it works.
Astonishing - I couldn't work like this.

>> Experience: good features are self-explaining. A function which
>> returns an iterator because of a simple word in it's body is not.
>
> A developer who's never seen the yield keyword before need only learn what
> it is once. http://php.net/yield Problem (to be) solved.

And my experience is also, the best documentation is self-explanation.
function bla() { yield.} isn't self explanatory. But yielder bla() {
yield } is. (Or let's say more self-explanatory than just function.)

>> Experience: They will make stupid mistakes, because they mix yield
>> function with normal functions.
>
> And the compiler will slap them for it.

The idiots are always smarter. :)
"And why do we need to look into the error-log? Too much warnings to
see anything."
"Error-log? I turned it off, because this bullshit caused that the
discs run full."

>> Experience: They will make stupid mistakes, because they will look for
>> "return" instead for "yield".
>
> And they won't find it, but hey look, what's this yield thing, I wonder what
> that does: http://php.net/yield

"Fine, a function without return value. Must be the bug I searched
for. WTF has this programmer made there? I remove the call and
everything will work fine. Trying it out, voilla it works, the script
doesn't fail anymore..."
Just one of millions of possibilities.

>> Experience: Not using the same name will remove a little bit pressure
>> from "busy" programmers
>
> Developers who work with other people's code (and that's who you're talking
> about) routinely have to spend time understanding the purpose of a given
> function. To assume that one can pretend to understand a function without

You dream. You don't have time. You need to get things done. :)

> having seen and questioned an unfamiliar keyword like "yield" is ridiculous
> from the outset.

In 50 lines of code yield will be just overseen.

But I meant something different: I thought of documentation. Maybe
someone reads the docs. Really! In the docs he will find functions.
And in the function this "yield". He dosn't want to know that. It
makes stress. "Why do I need to know how yield functions work, I
barely understand functions."
So this is systematically wrong. Right would be, that yield is an own
chapter. Will be easier if a generator is not a function.

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 07/25/2012 04:25 PM, Alex Aulbach wrote:
> In 50 lines of code yield will be just overseen.
>
> But I meant something different: I thought of documentation. Maybe
> someone reads the docs. Really! In the docs he will find functions.
> And in the function this "yield". He dosn't want to know that. It
> makes stress. "Why do I need to know how yield functions work, I
> barely understand functions."
> So this is systematically wrong. Right would be, that yield is an own
> chapter. Will be easier if a generator is not a function.

I'm with Sara on this one. A generator is enough like a function that we
don't need a new keyword for it. We typically don't get too pedantic in
PHP concepts and try to keep things simple. What we call an array isn't
technically an array either. It's an ordered map, but it looks enough
like an array that it is simpler to just call it that.

And objects technically have methods or member functions, not functions,
but we don't have a method/member keyword either.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/26 Yahav Gindi Bar <[email protected]>:
> "yielder" sounds quite weird don't you think (but my native language is not English too.. so don't blame me at english stupid conclusions!)
>
>> Fact: generator is not a good keyword, because too common.
> I can't see the connection... people relate the generator keyword to the iterators so what's the problem using it?

PHP will just complain in existing scripts if you use "generator" as
function-name and stops compiling. I think this is stupid, but that's
a completly different discussion.

> what about using the "iterator" name as generators keyword? because it does return iterators...

well, wouldn't think, that it can be that easy.

> iterator foo() { ... yield $bar; ... } sounds OK for me... and got a meaning too.
> though it can confuse some people with the original iterators...

But it's just what it does.

> BTW: I still don't think that the generators need a unique word and I suggest using functions, but I didn't read al the mails chain, so I assume that I'll find there the answer.

Of course you will!
<making gestures>These are not the droids your looking for. Ups. wrong line. :)


--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

> The implementation is outlined in the RFC-stub here:
> https://wiki.php.net/rfc/generators
>
> Before going any further I'd like to get some comments about what you
> think of adding generator support to PHP.

Some notes on the RFC:
1. I think we should support rewind() by just creating a new generator
instance (i.e. doing the same that is done when generator is called for
the first time). If it depends on the resource that generator changes as
a side effect, so be it. rewindable() looks like unnecessary
complication which IMHO will not be useful in most cases.

2. I understand the pre-yield code is called on current(). What about
key()? I think it makes sense to call it there too - i.e. pre-yield code
is called whenever first key() or current() - it should be made explicit.

3. return values. I think non-empty return in generator should produce a
notice or E_STRICT.

4. What happens to the state variables when generator is cloned? Just
addref or real cloning for objects?

5. Are multiple yields allowed? I.e. the rfc mentions something like
yield yield $a - what that would mean? I'd allow yield only be applied
to variable expression (lval) because double yield doesn't make sense to
me, but maybe I miss something.

6. “Sending values” section seems to be missing. Especially useful would
be to cover what happens with keys there and what is the syntax there -
is it just "$a = yield;"? Or does it mean when yield is used in
expression it becomes incoming yield? And, last but not least - do we
need sending into generators at all?

6. What happens if you send into a by-ref generator? Is the data sent
by-ref then? What if it's an expression that can't be send by-ref?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

I too don't think that a new keyword is necessary for this case. Let's
not forget that it is a common practice to document functions with doc
blocks, which further helps understanding what it does.

/**
* @return Generator
* @yield string
*/
function generate() {
...
yield $foo;
...
}

Cheers,
Bernhard

2012/7/26 Alex Aulbach <[email protected]>:
> 2012/7/26 Yahav Gindi Bar <[email protected]>:
>> "yielder" sounds quite weird don't you think (but my native language is not English too.. so don't blame me at english stupid conclusions!)
>>
>>> Fact: generator is not a good keyword, because too common.
>> I can't see the connection... people relate the generator keyword to the iterators so what's the problem using it?
>
> PHP will just complain in existing scripts if you use "generator" as
> function-name and stops compiling. I think this is stupid, but that's
> a completly different discussion.
>
>> what about using the "iterator" name as generators keyword? because it does return iterators...
>
> well, wouldn't think, that it can be that easy.
>
>> iterator foo() { ... yield $bar; ... } sounds OK for me... and got a meaning too.
>> though it can confuse some people with the original iterators...
>
> But it's just what it does.
>
>> BTW: I still don't think that the generators need a unique word and I suggest using functions, but I didn't read al the mails chain, so I assume that I'll find there the answer.
>
> Of course you will!
> <making gestures>These are not the droids your looking for. Ups. wrong line. :)
>
>
> --
> Alex Aulbach
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, Jul 25, 2012 at 11:00 PM, Jared Williams
<[email protected]> wrote:
> Though here is seemingly another problem, though it could be within
> spl's MultipleIterator()

Thanks, this is fixed now (see
https://github.com/nikic/php-src/commit/268740d9848d435054ce73a8cfe36b2b732cd1f7).
It turned out that you have to implement the Iterator interface before
assigning the get_iterator handler.

Again, thanks for testing the patch and providing useful feedback :)

Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/26 Bernhard Schussek <[email protected]>:
[about doc-blocks]

Fact: Doc blocks are not forced by the language.
Fact: For an IDE an own keyword will help the parser to distinct
faster/easier between "normal" functions and a generator.

Experience: IDEs will have their problems implementing this - think at
first try this isn't implemented with all consequences, so they may
not be helpful to see the difference.

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/26 Rasmus Lerdorf <[email protected]>:
> A generator is enough like a function that we
> don't need a new keyword for it. We typically don't get too pedantic in
> PHP concepts and try to keep things simple. What we call an array isn't
> technically an array either. It's an ordered map, but it looks enough
> like an array that it is simpler to just call it that.

Hm. I thought a long time about this. Has a technical component and
opens up a philosophical questions.

The technical part: There're many not so well made concepts in PHP.
I'm here with your opinion, we shouldn't rename arrays to ordered maps
and so on. Should be only changed if really needed.
Generators here are different. Reasons:

A) They are new. They're not ready yet. We can change them.

B) You say "They are functions enough to be used like a function."
Won't this lead to a point when we say "Ok, lets use function for
nearly anything"? Is an array of functions not also a function? :)

What I mean: Is it good to soften a weak concept more than really needed?
It doesn't matter how we name new things, but they should be
distinguishable, self-explaining, *not only* because of the new
feature, but also because of the old one!

C) I deleted this point and was too lazy to rename the others. :)

D) If we have options in development, which all are more or less right
and it can't be decided between them, then it's in general always
right to choose the option, which offers more opportunities. In this
case to choose a new keyword, because it gives us the option, that if
we find out, that it was a bad idea, we can go back to the current
implementation or choose another. This isn't possible, if we choose
the current implementation. Ok, it's possible, but the reasons must be
really, really hard in this case.

E) Generators are a relatively new concept. There may be more such
ideas, better ideas, changes, and what then? See D)



My (more or less) philosophical arguments are (maybe this part will
become a little bit off-topic):

1) The bigger the language grows, the more we need to think about how
to implement new features.
I think it's a bad argument to say "we made this and that not so
ideal, so we can make this also. Don't be so idealistic." :)
I think it's a duty to make new things more logical and more
self-explaining and more fitting into the rest. Always, and the bigger
it is, the more it must be done.

2) We should do things better, if we can.
This opens two questions. First: Is a new keyword better than none,
second: can we?

The first is really difficult to answer. Of course democracy will decide.

The second is already answered, it's currently just a question of
naming. If we want we'll find a name.

3) When implementing new things, my opinion is, that conservatism is a
luxury good, because once implemented, it will only be changed, if
really needed. See D). And from 2): We should do things better. This
means if possible and not if really needed.

4) We're no parliament, where we are voted into to deliver wishes.
We're free. These means two things: We don't need to look at the
"mass" of PHP-programmers, which never heard about this new feature
before they first will see it. But we can. And maybe we should,
because they are the users of what we do.
And we don't need to look at all the others. There is just no need to.
They didn't even use PHP. :)

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Lester Caine wrote:
>> Fact: yield makes functions some kind of "different".
>>> >
>> Yes, they turn normal functions into continuation functions (functions
>> which can be exited and reentered dynamically).
>
> But WHY would you not simply put the function that is handling the returned data
> in place of the yield?
> Why do you want to keep exiting and re-entering the 'do loop' when the data can
> simply be forwarded direct to a function to handle it?

I'll ask again since no one has answered ...

In a different way ...
Is the only thing that changes the 'function' into a 'generator' replacing the
call to process the data with 'yield'? ( That would be 'SUSPEND' in an SQL
procedure ) ...

So how DOES an IDE work out the flow in order to correctly check that variables
are defined?

As always, my IDE provides a lot of 'sexy' stuff so that I don't need to have it
built in to the language, and I still can't see how a lot of what is being
loaded in helps with performance which is the only thing that I am interested
in. Performance wise why is yield better than just directly calling a function
to handle the data?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Fri, Jul 27, 2012 at 9:56 AM, Lester Caine <[email protected]> wrote:
> I'll ask again since no one has answered ...
>
> In a different way ...
> Is the only thing that changes the 'function' into a 'generator' replacing
> the call to process the data with 'yield'? ( That would be 'SUSPEND' in an
> SQL procedure ) ...
>
> So how DOES an IDE work out the flow in order to correctly check that
> variables are defined?
>
> As always, my IDE provides a lot of 'sexy' stuff so that I don't need to
> have it built in to the language, and I still can't see how a lot of what is
> being loaded in helps with performance which is the only thing that I am
> interested in. Performance wise why is yield better than just directly
> calling a function to handle the data?

Lester Caine and Alex Aulbach,

may I ask you to continue this discussion in a separate thread? I am
really interested in constructive responses about the generator RFC,
but your discussion is generating a lot of noise, which makes it very
hard for me to pick out the few mails that are of interest to me.

If you could open a new thread (like "Generator keyword") it would help a lot.

Thanks,
Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Nikita Popov wrote:
>> I'll ask again since no one has answered ...
>> >
>> >In a different way ...
>> >Is the only thing that changes the 'function' into a 'generator' replacing
>> >the call to process the data with 'yield'? ( That would be 'SUSPEND' in an
>> >SQL procedure ) ...
>> >
>> >So how DOES an IDE work out the flow in order to correctly check that
>> >variables are defined?
>> >
>> >As always, my IDE provides a lot of 'sexy' stuff so that I don't need to
>> >have it built in to the language, and I still can't see how a lot of what is
>> >being loaded in helps with performance which is the only thing that I am
>> >interested in. Performance wise why is yield better than just directly
>> >calling a function to handle the data?
> Lester Caine and Alex Aulbach,
>
> may I ask you to continue this discussion in a separate thread? I am
> really interested in constructive responses about the generator RFC,
> but your discussion is generating a lot of noise, which makes it very
> hard for me to pick out the few mails that are of interest to me.
>
> If you could open a new thread (like "Generator keyword") it would help a lot.

Nikita - I am looking for a well reasoned argument as to why generator has to be
added at all! 'Just because it can be' is not a valid argument, but perhaps you
could add to the RFC the performance implication or advantage of what is being
proposed. That would at least be some comparison with the current methods of
doing the same thing?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
>
> Nikita - I am looking for a well reasoned argument as to why generator has
> to be added at all! 'Just because it can be' is not a valid argument, but
> perhaps you could add to the RFC the performance implication or advantage of
> what is being proposed. That would at least be some comparison with the
> current methods of doing the same thing?
>
>


If you read the RFC you will see all of these issues are already
addressed there.

https://wiki.php.net/rfc/generators#performance

"You can find a small micro benchmark at
https://gist.github.com/2975796. It compares several ways of iterating
ranges:"

What part of this discussion led you to believe such a ridiculous
argument as to why generator were introduced? I'm glad to see that
while seeking reason you are also demonstrating it.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 27/07/12 13:23, Lester Caine wrote:
> Nikita Popov wrote:
>>> I'll ask again since no one has answered ...
>>> >
>>> >In a different way ...
>>> >Is the only thing that changes the 'function' into a 'generator'
>>> replacing
>>> >the call to process the data with 'yield'? ( That would be
>>> 'SUSPEND' in an
>>> >SQL procedure ) ...
>>> >
>>> >So how DOES an IDE work out the flow in order to correctly check that
>>> >variables are defined?
>>> >
>>> >As always, my IDE provides a lot of 'sexy' stuff so that I don't
>>> need to
>>> >have it built in to the language, and I still can't see how a lot
>>> of what is
>>> >being loaded in helps with performance which is the only thing that
>>> I am
>>> >interested in. Performance wise why is yield better than just directly
>>> >calling a function to handle the data?
>> Lester Caine and Alex Aulbach,
>>
>> may I ask you to continue this discussion in a separate thread? I am
>> really interested in constructive responses about the generator RFC,
>> but your discussion is generating a lot of noise, which makes it very
>> hard for me to pick out the few mails that are of interest to me.
>>
>> If you could open a new thread (like "Generator keyword") it would
>> help a lot.
>
> Nikita - I am looking for a well reasoned argument as to why generator
> has to be added at all! 'Just because it can be' is not a valid
> argument, but perhaps you could add to the RFC the performance
> implication or advantage of what is being proposed. That would at
> least be some comparison with the current methods of doing the same
> thing?
>
Argh. I am trying to avoid this completely ridiculous thread of
discussion that has grown well beyond any reasonable length. But I
should just say this.

Generators are being added because they make things easier. The
function-with-yield model of writing iterators is much easier, faster,
and far less verbose than manually creating a class and implementing the
iterator interface. This is why they are being added.

They also might be a bit faster than Iterator classes, I don't know. But
the main point is they are a powerful feature that greatly simplifies
creation of iterators.

I will not discuss further on this point.

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Sherif Ramadan wrote:
> https://wiki.php.net/rfc/generators#performance
>
> "You can find a small micro benchmark at
> https://gist.github.com/2975796. It compares several ways of iterating
> ranges:"
>
> What part of this discussion led you to believe such a ridiculous
> argument as to why generator were introduced? I'm glad to see that
> while seeking reason you are also demonstrating it.

The micro benchmark is just that, and is not as far as I can see testing the
sort of iterating process that would happen normally when going through a data
set. It simply times the iterator, but does not compare like with like!

The question I am asking is if USING 'xrange' to feed a feed a function and use
the results is faster than 'urange' simply using the iterator to call the
handling function DIRECTLY. To fix this benchmark what I am missing is how the
'yield' approach would be used to build the $result[] array. This may be obvious
to some of you, but I'm missing something to help me understand just what is
planned here :(

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
>
>> The micro benchmark is just that, and is not as far as I can see testing
> the sort of iterating process that would happen normally when going through
> a data set. It simply times the iterator, but does not compare like with
> like!
>
> I hear your concerns about performance, and you're good to have them. So
to look at a real-world code base, I'd offer Facebook where we transformed
our data fetching classes from a form of iterator to use generators. The
result (exclusive of underlying data fetch) was nearly even, with a slight
gain on the side of generators (sadly no, I can't share the raw data with
you).

Of course, this is also meaningless since we're talking about the HipHop
implementation of generators and not PHP's, but there you go.

-Sara

On Wed, Jul 25, 2012 at 10:36 PM, Lester Caine <[email protected]> wrote:
> But WHY would you not simply put the function that is handling the returned
> data in place of the yield?
> Why do you want to keep exiting and re-entering the 'do loop' when the data
> can simply be forwarded direct to a function to handle it?

This question has come up a few times now, i.e. why one can't just use
callbacks. So I added a section about this, explaining it with a few
examples: https://wiki.php.net/rfc/generators#why_not_just_use_callback_functions

Hope it helps,
Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Thu, Jul 26, 2012 at 2:20 AM, Stas Malyshev <[email protected]> wrote:
> Hi!
>
>> The implementation is outlined in the RFC-stub here:
>> https://wiki.php.net/rfc/generators
>>
>> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
>
> Some notes on the RFC:
> 1. I think we should support rewind() by just creating a new generator
> instance (i.e. doing the same that is done when generator is called for
> the first time). If it depends on the resource that generator changes as
> a side effect, so be it. rewindable() looks like unnecessary
> complication which IMHO will not be useful in most cases.

I think the best thing to do is neither. I.e. don't support rewinding
and also don't provide a rewindable() function. I think that the
concept of generators implies that it is a one-time data stream.
Rewinding would fight the very nature of the concept. I think the
currently implemented behavior of rewind() being a no-op is okay, but
one could obviously also throw an exception when rewind() is called
more than once, to make errors easier to see.

> 2. I understand the pre-yield code is called on current(). What about
> key()? I think it makes sense to call it there too - i.e. pre-yield code
> is called whenever first key() or current() - it should be made explicit.

All the Iterator functions (and send()) will move to the first yield
before performing their respective action. This is also mentioned in
the RFC:

> If the generator is not yet at a ''yield'' statement (i.e. was just created
> and not yet used as an iterator), then any call to ''rewind'', ''valid'', ''current'',
> ''key'', ''next'' or ''send'' will resume the generator until the next ''yield''
> statement is hit.

> 3. return values. I think non-empty return in generator should produce a
> notice or E_STRICT.

Non-empty return values currently throw an E_COMPILE_ERROR. I think
that's okay as doing `return $foo` in a generator is clearly some kind
of bug.

In the future, should yield delegation be implemented, the return
value would become meaningful again, as it would be the result of the
delegation instruction. This is important for coroutine-based parsing
code, so that you can write $result = yield* $this->parseSomething();.

> 4. What happens to the state variables when generator is cloned? Just
> addref or real cloning for objects?

Cloning currently just uses addref everywhere. I'm not really sure
what the right behavior is in that situation. Generally I think that
cloning a generator is a rather strange thing to do, so it might make
sense to drop cloning-support altogether. At least I can't really
imagine a use case for it.

> 5. Are multiple yields allowed? I.e. the rfc mentions something like
> yield yield $a - what that would mean? I'd allow yield only be applied
> to variable expression (lval) because double yield doesn't make sense to
> me, but maybe I miss something.

yield yield $a would basically first yield $a and then receive some
value (via send) and yield that value again. Nothing you'd normally do
;) It was mentioned only as a syntax ambiguity consideration.

Actually I added some additional parenthesis requirements for yield.
For example you'd have to write the above as `yield (yield $a)` now
(which should be slightly more clear). I haven't yet reflected this
change in the RFC, but I'll add a section on it later.

> 6. “Sending values” section seems to be missing. Especially useful would
> be to cover what happens with keys there and what is the syntax there -
> is it just "$a = yield;"? Or does it mean when yield is used in
> expression it becomes incoming yield? And, last but not least - do we
> need sending into generators at all?

Yeah, I haven't written that section yet. But it is fairly simple: If
you go $generator->send($foo) then $foo will be the result of the
current `yield` expression. And yes, this also works with keys and
values. All of the following are valid:

$data = yield;
$data = (yield $value);
$data = (yield $key => $value);

The first case is the most common though. I.e. you usually use it
either as a generator or a reverse generator, not both. But doing both
is also common for cooperative multitasking etc.

Regarding the last question: I think the feature is worth adding. It
is a very powerful concept that is hard to implement otherwise. Useful
in particular for things like parsing and multitasking.

> 6. What happens if you send into a by-ref generator? Is the data sent
> by-ref then? What if it's an expression that can't be send by-ref?

No, sending is always by-value. By-ref only affects the yielding part.

Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 07/26/2012 11:36 PM, Alex Aulbach wrote:
> 1) The bigger the language grows, the more we need to think about how
> to implement new features.
> I think it's a bad argument to say "we made this and that not so
> ideal, so we can make this also. Don't be so idealistic." :)
> I think it's a duty to make new things more logical and more
> self-explaining and more fitting into the rest. Always, and the bigger
> it is, the more it must be done.
>
> 2) We should do things better, if we can.
> This opens two questions. First: Is a new keyword better than none,
> second: can we?

Both of these points essentially argue that naming the ordered maps
"arrays" in PHP was somehow not ideal and we (well, I in this case)
should have done better. I completely disagree. One of the strengths of
PHP is that it scales. It scales up to the largest sites in the world
while at the same time it scales down to weekend warriors. Doing both in
the same codebase is a challenge.

Scaling up is something very technical people like yourself understands
well. It is usually all about getting the architecture right and
removing global locks and other bottlenecks. However, scaling down is
not a technical problem but rather a philosophical one. It is about the
overall approach, coming up with ways to make complicated concepts
simple to understand, great documentation with simple examples and
presenting an approachable ecosystem which extends well beyond the
language itself.

Very early versions of PHP v1 actually had distinct list, map and set
implementations but I replaced those early on with a unified hybrid
ordered map implementation and just called it the "Array" type. The
thinking was that in almost all situations in a Web app, an ordered map
can solve the problem. It looks and acts enough like an array that it
can be used in situations that call for an array and it eliminates the
problem of presenting the user with 3 or 4 types and related keywords
and syntax that forces them to try to figure out which one to use when.
This decision was made in 1994 and apart from a few pedantic naming
complaints over the years, I think this particular decision has stood
the test of time.

I don't think this generator question is any different. We need to
explain generators in the simplest way possible. The simplest way to
explain generators is to not even worry about them being generators at
all. Simply say that functions can now return arrays one element at a
time using the new yield keyword. That's all.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Rasmus Lerdorf wrote:
> I don't think this generator question is any different. We need to
> explain generators in the simplest way possible. The simplest way to
> explain generators is to not even worry about them being generators at
> all. Simply say that functions can now return arrays one element at a
> time using the new yield keyword. That's all.

It's this 'concept' that I am having trouble seeing in the general process that
is required using PHP to generate web pages. At the end of the day I have to
generate the finished page or sub-page so I need all the results anyway. Part of
my own problem in understanding may be that all my persistent data is in a
database, and processing the SQL queries to efficiently serve up only the data
needed for that particular page is paramount for speed. SQL has the concept of
SUSPEND in procedures, but one would not use that here due to the processing
overheads. One builds the array of results and processes it to provide the data
to be fed to the client either while getting the dataset back from the database
( the html elements form part of the query ) or the much faster approach, you
get only the data stored in the initial array, and then iterate that array to
add the wrapper. Since in many shared hosting cases the database is on another
machine, you want to keep the amount of traffic between machines as small as
possible. OR is the point of this concept that we can suspend operation and
return later to do the next set of the list?

In the examples given so far, even the new ones on why 'callback' does not work,
understanding WHAT the end list of data is going to contain is difficult to work
out and picking up the increasing amount of similar code being added to
libraries makes maintaining them ever more difficult. But then perhaps I'm just
getting too old for this and it's time to throw in the towel :( I'm certainly
not enjoying all the agro keeping things working at all ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 07/27/2012 11:59 PM, Lester Caine wrote:
> Rasmus Lerdorf wrote:
>> I don't think this generator question is any different. We need to
>> explain generators in the simplest way possible. The simplest way to
>> explain generators is to not even worry about them being generators at
>> all. Simply say that functions can now return arrays one element at a
>> time using the new yield keyword. That's all.
>
> It's this 'concept' that I am having trouble seeing in the general
> process that is required using PHP to generate web pages. At the end of
> the day I have to generate the finished page or sub-page so I need all
> the results anyway.

Sure, but that doesn't mean it has to all be in memory at the same time.
You can read lines from a large file line-by-line, process that line and
output the result before you move onto the next line.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Rasmus Lerdorf wrote:
>>> I don't think this generator question is any different. We need to
>>> >>explain generators in the simplest way possible. The simplest way to
>>> >>explain generators is to not even worry about them being generators at
>>> >>all. Simply say that functions can now return arrays one element at a
>>> >>time using the new yield keyword. That's all.
>> >
>> >It's this 'concept' that I am having trouble seeing in the general
>> >process that is required using PHP to generate web pages. At the end of
>> >the day I have to generate the finished page or sub-page so I need all
>> >the results anyway.
> Sure, but that doesn't mean it has to all be in memory at the same time.
> You can read lines from a large file line-by-line, process that line and
> output the result before you move onto the next line.

Exactly ... when uploading the NLPG csv files I process them line at a time and
store to the database. I always have ... which is why I don't recognise the
initial 'complaint' that justified adding this. These files can be 100Mb+ so
there is no way one would process them by reading the whole lot in as the
'example' gave. You just call the function that processes the particular type of
line which is based on the first two characters ... after reading the line.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 07/28/2012 12:37 AM, Lester Caine wrote:
> Rasmus Lerdorf wrote:
>>>> I don't think this generator question is any different. We need to
>>>> >>explain generators in the simplest way possible. The simplest way to
>>>> >>explain generators is to not even worry about them being
>>>> generators at
>>>> >>all. Simply say that functions can now return arrays one element at a
>>>> >>time using the new yield keyword. That's all.
>>> >
>>> >It's this 'concept' that I am having trouble seeing in the general
>>> >process that is required using PHP to generate web pages. At the end of
>>> >the day I have to generate the finished page or sub-page so I need all
>>> >the results anyway.
>> Sure, but that doesn't mean it has to all be in memory at the same time.
>> You can read lines from a large file line-by-line, process that line and
>> output the result before you move onto the next line.
>
> Exactly ... when uploading the NLPG csv files I process them line at a
> time and store to the database. I always have ... which is why I don't
> recognise the initial 'complaint' that justified adding this. These
> files can be 100Mb+ so there is no way one would process them by reading
> the whole lot in as the 'example' gave. You just call the function that
> processes the particular type of line which is based on the first two
> characters ... after reading the line.

Great, so you recognize the use-case. Now you just need to get to the
next step which is that instead of having the iterating part call out to
the processors for each iteration sometimes it is convenient to have it
be processor-centric and have the processors be able to call the
iterator to get the next element without duplicating that code in every
processor.

-Rasmus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/28 Rasmus Lerdorf <[email protected]>:
> Very early versions of PHP v1 actually had distinct list, map and set
> implementations but I replaced those early on with a unified hybrid
> ordered map implementation and just called it the "Array" type. The
> thinking was that in almost all situations in a Web app, an ordered map
> can solve the problem. It looks and acts enough like an array that it
> can be used in situations that call for an array and it eliminates the
> problem of presenting the user with 3 or 4 types and related keywords
> and syntax that forces them to try to figure out which one to use when.

I think I remember that. I hated how it was done in Perl and I loved it in PHP.

> This decision was made in 1994 and apart from a few pedantic naming
> complaints over the years, I think this particular decision has stood
> the test of time.

> I don't think this generator question is any different. We need to
> explain generators in the simplest way possible. The simplest way to
> explain generators is to not even worry about them being generators at
> all. Simply say that functions can now return arrays one element at a
> time using the new yield keyword. That's all.

Well. I think you're right, saying this is not technical but
philosophical. So I will put aside all my technical arguments, because
they won't bring us further here.

From the sight of now we can say arrays like in PHP have been a good
concept. But in 1994 I must say, that was a brave decision!
So the question is: Can we say this for functions, too? What will we
say over those "functions" in 2030?

Thinking this from all sides I must admit, that you're right. Some
details of my thinking:

- There will be more than generators and such stuff, which - with the
same technical reasons - will also need new keywords. And this in the
end ugly.
- In the long run, it always was a good idea to introduce as few as
possible new language constructs, because it is easier to remember.
- You will then programm without an IDE only in very rare cases.
- Programmers will be used to it over time.

BTW: This thinking brought me to other aspects, but that's another mail.

And I have something on my mind, I can't forget: How can we reduce the
fuckuops in the beginning as much as possible?
Docs - ok! But I always come back to the same thinking: Is it enough?
And I think not in this case, because of the big difference between
now and then. It's a difference if you introduce a new thing in the
beginning or after 18 years.

Hm. I know, some will say "not again", but how about an *optional*
keyword? This follows also some "standards" in PHP (thinking of
"static", "public" etc. which are also "some kind of optional", so we
know that concept already).
Optional keywords are also used in SQL, where it helps to make a query
more self-descriptive. Not more or less should it be here.

How it works: PHP will warn (E_STRICT) if using a function as
generator without that optional keyword. Maybe it's possible to turn
that feature off, if you don't like that and in future the default
warning is removed. From aspect of parser the keyword "generator" will
have no implications (handled like a comment), because it will only be
a keyword, if "function" follows.

Suggested syntax will look like this:

[generator] function bla() { ... yield ...}

I think this could help to remove some of the ugliest fuckups, when
introducing it. And - this is my secret hope :) - this will kill the
need for discussion of this *now*. The future will show us, if this is
accepted/needed or not. Because who knows? This gives also more
options for the future and is in my eyes good design.

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov <[email protected]> wrote:
>> 5. Are multiple yields allowed? I.e. the rfc mentions something like
>> yield yield $a - what that would mean? I'd allow yield only be applied
>> to variable expression (lval) because double yield doesn't make sense to
>> me, but maybe I miss something.
>
> yield yield $a would basically first yield $a and then receive some
> value (via send) and yield that value again. Nothing you'd normally do
> ;) It was mentioned only as a syntax ambiguity consideration.
>
> Actually I added some additional parenthesis requirements for yield.
> For example you'd have to write the above as `yield (yield $a)` now
> (which should be slightly more clear). I haven't yet reflected this
> change in the RFC, but I'll add a section on it later.
>
>> 6. “Sending values” section seems to be missing. Especially useful would
>> be to cover what happens with keys there and what is the syntax there -
>> is it just "$a = yield;"? Or does it mean when yield is used in
>> expression it becomes incoming yield? And, last but not least - do we
>> need sending into generators at all?
>
> Yeah, I haven't written that section yet. But it is fairly simple: If
> you go $generator->send($foo) then $foo will be the result of the
> current `yield` expression. And yes, this also works with keys and
> values. All of the following are valid:
>
> $data = yield;
> $data = (yield $value);
> $data = (yield $key => $value);
>
> The first case is the most common though. I.e. you usually use it
> either as a generator or a reverse generator, not both. But doing both
> is also common for cooperative multitasking etc.
>
> Regarding the last question: I think the feature is worth adding. It
> is a very powerful concept that is hard to implement otherwise. Useful
> in particular for things like parsing and multitasking.
>
>> 6. What happens if you send into a by-ref generator? Is the data sent
>> by-ref then? What if it's an expression that can't be send by-ref?
>
> No, sending is always by-value. By-ref only affects the yielding part.

I now added the mentioned sections:

https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values

I also added a list of error conditions:

https://wiki.php.net/rfc/generators#error_conditions

Sorry for the delay,
Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php