[
Lists Home |
Date Index |
Thread Index
]
"Aaron Skonnard" <aarons@develop.com> wrote:
| I don't see how what you do after each "pull" would be any different
| than what you have to do within each call from SAX.
I agree. You must have missed my SAX rants :-)
| You still have to build a state machine with a pull-model API, but now
| your state machine can simply take the form of procedural refinement:
| [example omitted]
Well, procedure refinement rules out dispatch by more or less ruling out
polymorphism, right? Whatever little you have, you test on some "typing"
value and switch/if-else your way home. I don't know how realistic your
example was, but coding in that style would seem to make several very
strong assumptions about the nature of the input. Writing If-tests on
reader.LocalName wouldn't work too well (if at all) with mixed content,
for example. And unless the code were generated by a logic processor,
implementing a state machine as a deep tangle of if-elses is sheer
masochism, IMHO. So, maybe there isn't much depth to the data either...
Ah! Database tables! Got it:-)
I can also understand how many programmers would be more comfortable with
a procedural style of coding ("I do this, then this, maybe this...") as
opposed to the style where you have to distribute the state machine across
a bunch of callbacks. So there may be a productivity win, here.
All said and done, though, making state machines easier to implement is,
in my view, an outstanding problem of the various APIs. For example, I
think SAX parsers should make a semantic stack available to the app in
parallel with the open element stack it maintains internally. The code
framework is already there, why not leverage it? (There are two ways to
do this: stack semantic values for the app in classic parser style, or
stack handlers and deliver events only to the top of the stack.)
|
