[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold scripsit:
> It's not really all that different. But most developers are much more
> comfortable with the iterator design pattern than the observer design
> pattern. It's easier for them to see where, when, and why, each event
> gets fed into their code when they ask for the event rather than
> responding to it.
A fundamental difference is that state can be encoded in local variables
and recursion when using a pull API; you can have a routine which processes
an element and calls various routines to process its children, with
recursion when appropriate. This is essentially the method of
compiling by recursive descent as applied to XML.
In an event-handler environment, you have to maintain the state and the
recursion stack explicitly. This is painful and easy to get wrong.
In my Project T, I have to maintain complicated and messy state in
the upper level because the lower level is an event-driven SAX-style
push API.
--
Some people open all the Windows; John Cowan
wise wives welcome the spring jcowan@reutershealth.com
by moving the Unix. http://www.reutershealth.com
--ad for Unix Book Units (U.K.) http://www.ccil.org/~cowan
(see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif)
|
