- From: Joseph Kesselman <keshlam@us.ibm.com>
- Date: Tue, 26 Feb 2002 10:02:04 -0500
- To: Philippe Le Hegaret <plh@w3.org>
- Cc: David Brownell <david-b@pacbell.net>, WWW DOM <www-dom@w3.org>
It should also be noted that the Java Collection Classes are only one _suggested_ API that Java developers may want to use for their own convenience. Doing something different is not "noncompliant" any more than departing from the strict subset that a "clean" Java Bean is supposed to restrict itself to... and there are lots of Java objects out there, including many in Java's own libraries, which are not "clean beans". Java's lack of templates (or any other kind of code preprocessor) does mean that there may be some additional advantages to trying to use the same interfaces everyone else is using. But y'know, it really isn't any harder to design a convenience layer that wraps around the DOM APIs to expose them as Java Collections... and if you do it that way, you have the advantage that this layer can be ported to other environments as well. For example, if you want a DOMChildrenEnumerator, it's really pretty darned trivial to wrap one around either NodeList, NodeIterator, or TreeWalker (depending on which behavior you want under document mutation). If you really think this would be an important thing to add to the DOM, the best way to motivate that change would be to write such a glue layer, use it to establish which behaviors the users really want (and to show that there really is sufficient demand for those functions), and then demonstrate to the DOM WG that it is either sufficiently important architecturally or would achieve significant additional optimization -- preferably both -- if the DOM was enhanced to specifically support that usage model. I'm actually not completely opposed to extending the Java API (not that I have any say in the matter these days), but I really don't see a concrete benefit to be gained that a convenience library couldn't deliver just as well... or better. ______________________________________ Joe Kesselman / IBM Research
Received on Tuesday, 26 February 2002 10:25:29 UTC