>On the other hand, if we are going to promote the 'IDOM' be the standard
>binding, then I think a rename to DOMXXX must be done.

It's a pity C++ doesn't have a usable/portable/reliable equivalent of the
Java "package names" concept; that lack is what's forcing you to use DOM as
a prefix on the API names themselves.

I'm not worried about the rename, per se. I'm just slightly concerned about
having two systems -- whether directly or through a macro -- where the only
difference in nomenclature is the presence or absense of an underscore.
Gods know I've had enough typos where I've forgotten whether a particular
package does or doesn't have underscores in its name; they're easier to
diagnose when the typo results in class-not-found rather than
wrong-class-found.

As I said, I don't really have a better answer... but I'd almost prefer to
retain the IDOM name, or something else that distinguishes the two more
strongly. I can't fault you for not wanting to  flat-out rename the old
one, but it does make finding a good name for the new one much more
difficult... and I'd like to encourage folks to come forward if they _do_
have any good ideas in this area.


The real problem here -- the thing that makes the class name relevant -- is
the lack of an officially standardized abstract C++ API for the DOM. If we
had that, the majority of references to a specific implementation would
drop out -- basically, you'd only need to know which we were using when you
retrieve the DOMImplementation object or when you want to use features
which go beyond the standard DOM API -- and the risk of confusion would
drop somewhat as a result. The main challenges in doing that layer appear
to be memory management (could be solved by architecting a release()
operation but saying GC DOMs can get away with not calling it) and the
choice of binding for DOMString (which might be solvable via some
combination of templates or wrappers).



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to