And so says Reed Hedges on 07/09/05 10:02...
> (1) it's an extra pain in the neck for developers (i.e. 
> programmer-users) to worry about, especially coming from worlds like
> C and descendents where the notion of non-ascii character sets are a
> very recent addition and not a natural part of the language

I'd agree, if we were talking about C.  But we're talking about C++.
You can just have different setProperty or whatever methods that get
single-byte std::string, and multibyte... eh... what's the class for
that? :-)  whatever.

Oooh, interesting thought.  Would types and contextual names be allowed
to be unicode too?

> and (2) if we add the extra "encoding" field, then we can put off
> actually transitioning to unicode (or whatever) by saying that
> currently the only valid encoding is ascii.

Is that worth the trouble?  If we're not ready to go unicode, just don't
change the protocol yet.

                                               Lalo Martins
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
--                  mailto:[EMAIL PROTECTED]
GNU: never give up freedom       

vos-d mailing list

Reply via email to