Michel Fortin wrote: > On 2009-05-24 12:51:43 -0400, Daniel Keep <daniel.keep.li...@gmail.com> > said:
(Cutting us mostly going back-and-forth on what a callback api would look like. >> ... >> >> Like I said, this seems like a lot of work to bolt a callback interface >> onto something a pull api is designed for. >> >> ... >> >> Except of course that you now can't easily control the loop, nor can do >> you do fall-through on the cases. > > Again, my definition of a callback API doesn't include an implicit loop, > just a callback. And I intend the callback to be a template argument so > it can be dispatched using function overloading and/or function > templates. So you'll have this instead: > > bool continue = true; > do > continue = pp.readNext!(callback)(); > while (continue); > > void callback(OpenElementToken t) { blah(t.name); } > void callback(CloseElementToken t) { ... } > void callback(CharacterDataToken t) { ... } > ... > > No switch statement and no inversion of control. Except that you can't define overloads of a function inside a function. Which means you have to stuff all of your code in a set of increasingly obtusely-named globals or private members. Like elemAStart, elemAData, elemAAttr, elemAClose, elemBStart, elemBData, elemBAttr, ... One problem I see here is that you're going to spaghettify the code and state. For example, let's say I'm writing code to handle a particular element. I can't put the code and state for this into a single function, I have to break it out over several. One function for each event. This means I need to have all state variables visible from each function. So I have to start shoving the state into the owning object instead of on the stack. Whoops, I can't recurse now, can I? Sucks if I'm using any sort of hierarchical structure. I can't use the call stack, so I have to invent my own. I don't want to make every state variable a stack, so I put each component of the parser into a separate object which I can instantiate and kick off. And at that point, I've just reinvented SAX. Well, almost. I have control over the loop. I still can't simply break out of it; I've got to mess around with flags to get that done. Meanwhile, if I write that code with a PullParser, it's just a collection of normal functions, one per element type with all the related code together in one place. Or, if I don't want them all bundled together, I can dispatch to smaller functions. I have a feeling you're going to head down this path irrespective, so I'll just hope you can figure out a way to make the api not suck.