Thanks for the correction Mike. The typo also extends to the
Java language bindings on the W3C site (and also, I think both IBM
XML4j and SAXDOM have this mistake too)
> >So why not dispense with XMLNode altogether and make the Node
> >interface implement these functions? Simply define that expandEntities
> >is "always true" for HTML documents, or some such.
>
> Something like that is under consideration; I can't be more specific
> because the methods for doing this have not been nailed down yet.
No problem. Too bad you guys don't have the luxury of using function
overloading. :)
> >3) extra nit: the function names are overly verbose and option #2
> >would solve it.
> Whimper .... the function names are verbose because of the astonishingly
> complex web of constraints that they must satisfy. "Brevity" is actually
> one consideration, but less important than clarity, internal consistency,
> avoiding clashes with existing APIs in widespread use, compatibility with
> the name scoping scheme in ECMAScript .... etc.
I realize that, and I'm glad you guys are taking that into
consideration. One of the problems I had on my last project was that
I was using Lark, and I wanted to override the Element that Lark used
to build trees (I had my reasons for letting Lark build the tree,
relating to some third party code I had to interoperate with) with a
subclass that implemented swing.tree.TreeNode, however TreeNode
defines
public abstract Enumeration children()
but Lark's Element defines
public Vector children()
And as you know, you can't overload based on return types :(
In such cases, Java's inner classes yield a solution, which is to
use internal delegate classes
public class SuperNode implements TreeNode
{
public Node getDOMNode() { ... }
class DOMAdapter implements Node { .... }
}
-Ray