On Monday, 04/29/2002 at 09:37 EST, "Lenny Hoffman" <[EMAIL PROTECTED]> wrote: > I would agree that it is reasonable to nix the DOMString, but does anyone > object to that given that DOMString is explicitly specified in the W3C DOM > specification?
You may want to recheck the DOM spec. DOMString is explicitly explained as being a placeholder which DOM implementations can replace with whichever string implementation makes most sense in their environment as long as it supports UTF-16 text. The reference DOM bindings for Java, for example, use Java's own String type. From an efficiency point of view, that was definitely a good choice. From an interoperability point of view, in languages where there isn't a single obvious way to implement the DOM API -- such as in C++, where multiple options exist for memory management -- it's a lot less clear that this was a win... but the fact is that the DOM leaves this open. I've periodically argued that what we need is a generalized UnicodeString type, which would encapsulate the conversions between various encodings and string manipulation in these different spaces (eg, converting unicode character offset into UTF-16 encoding unit offset). If we had such a type, I would actually like to see DOMString bound to that in at least some implementations of the DOM. So from an architectural point of view, there may in fact be an argument for having an abstract DOMString superclass and using multiple inheritance and a bit of glue to bind whatever actual C++ string class is desired into that framework... or at least designing the code so a different string implementation can easily be plugged in (via the preprocessor?). But I don't think that's realistic in the real world, esp. as the choice of string may also get reflected back into the parser's DOM construction code. Another beautify theory killed by ugly facts... But to answer the question: NO, nobody will call you noncompliant if you replace DOMString by any other UTF-16 string type. If they don't like your choice, they may call you other things... but you probably can't please everyone. > I thought that with the original DOM > interfaces being officially supported and around longer that backwards > compatibility to it would be more important The C++ community is generally more willing to upgrade their code when they see an advantage to be gained than the Java community is -- mostly because they can do so without having to force end-users to also upgrade their environments. > what matters most to me is functional behavior and ease of use. What would matter most to me, if I were doing more C++ work (I'm focusing on Java for now) is performance on essential functions, followed by additional functions and their performance, followed by robustness (of the implementation; I'll take responsibility for my own code), followed by ease of use. If the last was the dominant factor, I'd stay in Java. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
