On Wed, Aug 22, 2012 at 12:11 PM, Lester Caine <les...@lsces.co.uk> wrote:

> Ferenc Kovacs wrote:
>
>> it doesn't make a difference, if you yield only once, and put that into a
>> loop,
>> or copy paste the yield line ten times.
>> yield always does the same thing, pass the execution to the caller.
>>
>
> I KNOW that I am sounding thick here but "you don't have to understand the
> underlying process, as it 'just works'." is exactly where I'm having the
> problem. Perhaps because some of these things ARE treated as 'magic' ? But
> I need to understand the work flow if I'm going to profile it and optimise
> use of this stuff. When working on data feeds from the database, HOW is
> everything in making it work at it's fastest. One way of doing things can
> be several orders of magnitude slower than another.
>

do you know how the goto, break, continue throw, etc. contstructs work?
from a userland developer point of view, the whole generator stuff is
explained in these few lines:

Generators work by passing control back and forth between the generator and
the calling code:

When you first call the generator function ($lines =
getLinesFromFile($fileName)) the passed argument is bound, but nothing of
the code is actually executed. Instead the function directly returns a
Generator object. That Generator object implements the Iteratorinterface
and is what is eventually traversed by the foreach loop:

Whenever the Iterator::next() method is called PHP resumes the execution of
the generator function until it hits a yield expression. The value of that
yield expression is what Iterator::current() then returns.
when you first call a generator function, it will return an instance of the
Generator class, which you can iterate over, which in turn will execute the
method body yield-by-yield (until the generator is depleted or you stop
iterating it).



>
> In this example, if I look at it as an SQL stored procedure, on every
> 'pass back to the caller' I get the next piece of data, so I'm getting a
> sequence of all the 'first' objects, followed by all the 'second' objects.
> What is consuming that data just takes what is given each time and
> processes it. Somewhere in this magic, the data is packaged so it can be
> passed, and it's yield that is packaging the return. In SQL that return
> would be a database record each time, with no relation to previous or next
> record, but I presume talk of 'auto-increment' is to automatically add a
> record count? And talk of 'returning arrays' only applies if 'yield'
> specifically outputs the next array element? It's this 'just looks like an
> array' that is getting me since the whole point is NOT to return an array
> of objects? In my method of working I can either build an array of records
> from the data feed, or simply handle each item in a sequence and throw it
> away. You don't want to build the array was the reason given for needing
> generators?


I can't really follow your sql example, but let's try this another way:
You understand how Iterators work, right? (
http://php.net/manual/en/language.oop5.iterations.php
http://www.php.net/manual/en/class.iterator.php)
The proposed generator implementation works the same way from the
consumer/caller perspective.
They call a function, which returns them a Generator object, which
implements the iterator interface, so the caller can iterate over the
returned object.
In the background, the original function body acts as the implementation of
the next() method of the iterator inteface, and the yield keyword is used
to mark the end of each next() call.
Does this make it more clear to you?

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Reply via email to