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

Joseph,
sorry for taking up to much of your valuable time.

Actually, all I want is just "trivial nodetype-to-method binding". You state 
in your follow-up email that this could be done by just using:

myvisitor.execute(mynode);

To my best knowledge, this proposal does simply **not** work (see 
explanation below). I agree with you that you can complicate the API very 
much, but I'd be perfectly happy with the simple nodetype-to-method binding, 
unless of course you can show me how to make it work with the approach you 
propose.

I will send you a more detailed description of a use case in the next few 
days.

Here's the promised explanation for why your proposal does not work:
The reason why myvisitor.execute(mynode) does not work is that at the point 
where this code is called the object you are dealing with is only known to 
be of class node.
At least in Java (and I believe also in C++), it is therefore always the 
"execute(Node n)" method of the visitor that is called, unless I introduce a 
cast, which I can not do without a switch statement, as I need to know where 
to cast to. Again, no matter what class "mynode" actually is, at the point 
of calling it is known to the runtime system only as a node, and therefore 
polymorphism fails.

If I use v.execute(this) inside of the subclass of node I want to use 
instead, it does work, because the language runtime actually types "this" 
appropriately - it knows now which class "this" actually means.


>From: "Joseph Kesselman" <keshlam@us.ibm.com>
>To: www-dom@w3.org
>Subject: Re: Type-safe iteration over the DOM in DOM 2 & 3?
>Date: Wed, 21 Mar 2001 16:01:42 -0500
>
>
> >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
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Received on Thursday, 22 March 2001 01:34:21 UTC