- From: <keshlam@us.ibm.com>
- Date: Wed, 14 Oct 1998 16:37:51 -0400
- To: www-dom@w3.org
> In particular, it might be true in a given implementation that > *every* class that implements Element also implements HTMLElement. Agreed. All that the DOM guarantees is that when you createElement it _will_ return a Node that implements Element. If it happens to also implement HTMLElement, as it will in an HTML document, that's fine; the important thing is that all its behavior when accessed as an Element matches that of the Element spec. Here's a worst-case example: It's possible (though ugly!) to ignore the normal class hierarchy entirely and implement all the Node interfaces in a single class. In this case, instanceof might report the Node as everything from an Attribute to a CDATASection, as well as the Element that it's currently configured as. A properly written DOM application should work as well with this as it would with a more normal OO-structured version. (One would hope that if you tried to call getSpecified against one of these "unified" nodes which is currently functioning as an Element, some diagnostically useful error message would be presented... but that's a quality-of-implementation detail.) For that matter, there aren't all that many languages that have really usable runtime type ID -- Java's support for instanceof is unusual -- and certainly a DOM implementation written in a non-OO language won't allow you to ask the question that way. If you want to check the type of a Node and care about portability, getNodeType() is the right answer. Admittedly, that doesn't distinguish an HTMLElement from an Element. But I think the solution is to either know which type of Document you generated (ask the DocumentImplementation?), or to use only the Element API and trust that if there's a behavioral shift you'll have been handed an Element that is somehow set up to Do The Right Thing. (I still want to know who coined the quote "Object-oriented programming makes good programmers better... and bad programmers obvious.") ______________________________________ Joe Kesselman / IBM Research Unless stated otherwise, all opinions are solely those of the author.
Received on Thursday, 15 October 1998 15:02:16 UTC