W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2000

Re: DocumentTraversal

From: <keshlam@us.ibm.com>
Date: Mon, 6 Mar 2000 13:07:54 -0500
cc: www-dom@w3.org
Message-ID: <8525689A.00639991.00@D51MTA03.pok.ibm.com>
>First: The DocumentTraversal methods appears to be an extension of the
Node
>Interface, rather than an additional interface that may be supported by
the
>Document.

Interesting thought.

We designed these to live on the Document with the other factory methods,
and to be passed their root node as an argument... but we _could_ have
instead designed them so the factory was invoked on the root node itself,
and had that association be implicit.  I agree that the latter is prettier
architecturally.

But consider the recent comment "You mean I have to cast to get access to
the DocumentTraversal methods? Yuck!" -- If these live on the Document
object, you may be able to cast once and hang onto the DocumentTraversal
through repeated operations on that document. If they live on individual
Nodes you'd have to cast each root node, probably every time unless you're
repeatedly iterating over a single subtree.

Unless the factory continues to take the root node as a parameter... in
which case I'm not sure the difference between this proposal and status quo
is large enough to make much difference.

I don't have a hugely strong opinion on this either way.


>Secondly, the expandEntityReferences flag on the factory method should
>really just be another constant that can be passed into whatToShow:
>SHOW_ENTITY_REFERENCE_EXPANSION or SHOW_ENTITY_REFERENCE_CHILDREN.


It could be another bit in that mask, true. I'm not sure this is a net
gain, though; it's conflating two seperate operations. Given that the
factory call is a relatively rare operation compared to actually using the
traversal objects, I'm not convinced that saving a parameter really gains
us anything. Especially as bits are a scarce resource; I don't expect us to
need more than 31 nodeTypes, and there's the workaround of moving the
nodeType test into a filter, but I'd rather not establish a precedent of
nibbling from both ends toward the middle.

And thinking about how I'd implement it, the first thing I'd be inclined to
do inside the factory would be to break SHOW_ENTITY_REFERENCE_EXPANSION out
into a separate boolean so it could be tested conveniently, and clear that
bit in the mask so I didn't have to special-case it when deciding how to
handle the rest. So saving a parameter might increase computation.

I think this winds up being a matter of style as much as anything else. My
instincts say to leave it as is. Your milage may vary.
______________________________________
Joe Kesselman  / IBM Research
Received on Monday, 6 March 2000 13:08:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:47 GMT