Re: Proposal for java-language-binding: use of collections framework

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