Re: Type-safe iteration over the DOM in DOM 2 & 3?

>The changes to the DOM, as outlined in
>the forementioned mail would be minimal.

That's what I'm not really convinced by.

Consider: Let's say we do provide Node.accept(). In doing so we must define
its behavior, otherwise this isn't a meaningful API. That means we have to
say which visitor method gets called back to. Once we've done so, we have
(a) fully defined the API for a DOM visitor, (b) fully nailed down what
happens when a node is visited.

Now let's say you want to take advantage of this to do more than the
trivial nodetype-to-method binding. The key word here is "Oops." If you
subclass the nodes to call back to different methods, code based on the
standard visitor behavior stops working. If you subclass them to call back
to additional methods, visitors which don't support those methods stop
working. If you handle this by calling back to a single shared method which
then dispatches to the additional behaviors, you've reintroduced your
select statement. If you try to handle it via RTTI/reflections -- only call
the additional methods if they're present -- you've got something which is
going to be difficult, at best, to implement in languages which don't
provide those facilities as primitives.

So far, I really don't see a good way to do this for  a portable API rather
than a specific class library.

Again: We're throwing around a lot of theoretical arguments here. I'm still
waiting for SPECIFIC use cases which would allow us to sketch out how we'd
code each of the alternatives and look at just how tractable, portable,
extensible and robust they really are.

At the moment, my own best estimate is that the design isn't as trivial as
it looks, and the need isn't well established enough to motivate spending
many more cycles on driving the design to either success or failure.

______________________________________
Joe Kesselman  / IBM Research

Received on Wednesday, 21 March 2001 16:02:12 UTC