XML API

[Daniel Keep]

Michel Fortin wrote:
> On 2009-05-24 12:51:43 -0400, Daniel Keep <daniel.keep.lists at 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.