----------------------------------------------- Joe Gregorio [EMAIL PROTECTED] Project Engineer MTS Systems Corporation
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > I really would have preferred to use some preexisting string > package rather than invent yet another new one. If we can > find something standard that does the job, I wouldn't mind > losing DOMString, although there would no doubt be a squawk > from the existing user base. > > Here were my requirements at the time we went with DOMString: > > No std library dependencies. There are still important platforms > (some from IBM, unfortunately) that do not support it. > No STL? Snif. Just for my own personal edification, which platforms don't support it? > 16 bit chars, not wchar_t, which is sometimes 16, sometimes > 32, depending on the platform. (DOM memory usage is > already a big sore point) > > Reference counting memory management. This goes along with > the rest of the DOM. An argument can certainly be made > for a non-reference counted C++ DOM, but whatever is chosen, > strings need to match everything else. > Why MUST strings match everything else? I usually make pointer vs value semactic decisions on a class by class basis depeding on how that object will be used. I realize consistency is important and I would definitely think it strange if DOM_Node had pointer semantics and DOM_Element had value semantics, but to me DOMString sits outside the DOM_* category. > Efficient const return of stored values. This means either > Java style immutable strings, or very efficient cloning > of mutable strings. > > Easy porting of existing Java string code to C++. > > And so, here we are with DOMString. > > -- Andy > > >
