On 2012-08-21 01:10, Lester Caine wrote:
For the third one ... I'm still waiting for some clarification on how
yield is SUPPOSED to work anyway? If you are using a 'generator' to
return a sequence of data elements, then just what does happen between
each call to the generator ... DOES the generator get called for each
value until something flags there are no more? I still don't see the
advantage of restructuring how things are called to get around a problem
which can just as easily be solved by proper design in the first place.
Have you even read the RFC yet? Calling a generator function returns an
instance of a Generator object. That object has a method interface -
described in the RFC. That interface is accessible to the foreach()
construct so the loop can iterate over the successive values returned by
the object.
If by "proper design" you mean your own personal preference for using
callbacks, that's also discussed in the RFC. You were told this last month:
On Sat, Jul 28, 2012 as 05:34 AM, Nikita Popov <nikita....@gmail.com> wrote
> On Wed, Jul 25, 2012 at 10:36 PM, Lester Caine <les...@lsces.co.uk>
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
But let's compare the two side-by-side.
So there is a "producer" that has or generates the successive elements
of a sequence, and a "consumer" that does something with each element in
turn. One can make a choice about which of the two - producer or
consumer - gets to drive the process.
In one (basically the Observer pattern), the producer drives, and the
consumer gets to observe by supplying a callback that the producer calls
for each new element. Since the producer has no idea about the internal
workings of the consumer, the consumer has to ensure that it can
properly resume the next time it is called.
In the other (basically the Iterator pattern), the consumer drives,
calling the producer each time a new element is required. Since the
consumer has no idea about the internal workings of the producer, the
producer has to ensure that it can properly resume the next time it is
called.
There are a couple of differences between using an observer and using an
iterator. The main difference is because at least one of the producer or
consumer needs to maintain its own state between iterations.
For the producer-driven observer approach, it is the consumer's job to
maintain state. - the producer's state is safe on the call stack.
For the consumer-driven iterator approach, it is the producer's job to
maintain state - the consumer's state is safe on the call stack.
In the observer approach, writing the state-maintenance code falls to
whoever is writing the consumer; the producer is unable to help with
that at all because it's different for each consumer.
In the iterator approach, writing the state-maintenance code falls to
whoever is writing the producer; that code is the same regardless of the
consumer.
As this proposal and existing implementations show, it is possible,
given the kernel behaviour of the iteration, to mechanically generate
all the state-handling and other boilerplate necessary to produce a
Generator object.
That's the main difference. The other difference is that in the case of
the iterator, in part because the code generation can be mechanised, the
iteration mechanism can be done in such a way that it fits in with the
iteration mechanisms that PHP already has built into the language: the
foreach() statement doesn't care whether it's iterating over an array or
an iterator or a generator. Either could be supplied at runtime.
In contrast, to achieve the analogous effect with an observer mechanism
would involve (among other things) searching for occurrences of control
flow statements that reference the sequence, excising those statements
and using them as the kernel for a callback method to be supplied to the
sequence producer ... but only if the sequence in question wants all
that done in the first place.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
