Re: Re: [PHP-DEV] [RFC] Generators

On 2012-08-22 04:35, Lester Caine wrote:

John LeSueur wrote:

Again, the case you've cited is probably not a case where generators give much advantage. But anytime the logic to produce some data becomes more complicated (Imagine that you needed to skip some of the lines in the .csv file based on some kind of filter), then being able to extricate the producer logic from the consumer logic is helpful.

But in my 'method of working' one simply changes the '$contact->' object and loads the one that matches the data you are handling. Sage, paypal, moneybox, nlpg and so on. I've a dozen or so data models currently. That is one of the differences. With the Iterator pattern that is being automated here, all the boilerplate of maintaining state between iteration steps is contained within the iterator object, and is the same for all uses of that object, so only needs to be written once (and, with this extension, that writing is automated). Using the Observer pattern like you do requires boilerplate to be written afresh for every distinct _use_ of the iterator. That boilerplate isn't directly related to the consumer's actual job but to the iteration process (limiting the range of producers that consumer can be fed from).

but I still can't see why the work flow has to be reorganised rather than simply following the natural flow that the job requires. The adjective "natural" would only apply if you always see iteration as the producer pushing its productions out to the consumer ("here - go work on this"), and never picture the situation as the consumer pulling them from the producer ("give me something to work on"). Otherwise it's just a different perspective.

The Observer pattern certainly does have its uses (otherwise it wouldn't be a pattern): if the "things being produced" are interpreted as "events being handled" ("hey, a new line of CSV has just come in!"), there may be multiple consumers interested in being notified when those events occur.