> > > I've just gone back over the rfc and I probably understand now why I was > getting confused. Actually it really does irritate that the first 'example' > on the page is simply the wrong way of doing it anyway. We should not be > propagating bad code like that and using it as justification for something > new just got my back up from the start. The extra "Why not just use > callback functions?" irritates more because again it's another poor > example. Drop the callback altogether and just add a call to process the > data using a suitable object ... > > Then the next example is an 'iterator' ... which you are right ... I do > not appreciate either, because they require an insane amount of overhead > for what would be easy if the first example had been done right! I did try > them, in the past, but the overhead outweighed any advantage and I can't > find them in any of the projects I work with apart as a blank frame in > ADOdb ... which nobody seems to use. > > So I'm working from the wrong base simply because interators also > introduced too much overhead for no gain. Now we are trying another fix to > make iterators work better? I suppose the next step is simply using 'yield' > without iterators? The iterator magic is only used to hide some of the > process flow where a simple object might work better. > > I CAN actually see where the use of yield might work, but I am probably > simply to stuck in my ways. Niktia's "A concrete example, which was > actually my initial motivation to write the generators patch:" is probably > another good example of why iterators are simply wrong more times than they > are right? > > So now you understand how the proposed Generator implementation works? If you think that Iterators require a bunch of boilerplate code, I can understand that, and that was one of the motivations behind the Generators rfc I guess. If you think that using Iterators (hence reversing the process control between the consumer and producer) is always wrong, I cannot agree with that. There are cases when you don't care about how the data get created/filtered, you just want to iterate over it, without the need to build a huge array and only start working on it, when the whole thing is ready. Your style of processing data is tightly coupling the generation of the data and the processing of the data, which works for you, but in some scenarios and for some people it is a bad architectural design.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu
