On 2012-08-23 00:10, Lester Caine wrote:
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.
But as far as I've been able to make out, your method _still_ has the
overhead of maintaining state during the iteration - only now it's each
consumer's responsibility to remember its state between successive
notifications by the producer. The producer can't help with that,
because each consumer has different maintenance requirements; managing
the iteration process has therefore been split across two distinct
objects with the consumer doing the hard part (which is why the producer
looks so simple).
I suppose if you're lucky the consumer doesn't need to remember any
state between one notification and the next, and it can treat every
dataum like it's the first. But that is hardly the general case.
To describe iterators further, here are a few links (note that they're
not necessarily the best - they're just the first non-Wikipedia,
non-Amazon links I got when Googling for "Design Patterns"):
http://www.dofactory.com/Patterns/PatternIterator.aspx
http://www.oodesign.com/iterator-pattern.html
http://sourcemaking.com/design_patterns/iterator
It might also help to compare the Observer pattern, in the special case
where the one-many relationship is actually one-one.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
