From: Michal Suchanek <hramrach@...>
Date: 2006-06-18T07:46:58+09:00
Subject: Re: Unicode roadmap?

On 6/17/06, Juergen Strobel <strobel@secure.at> wrote:
> On Sat, Jun 17, 2006 at 10:52:24PM +0900, Austin Ziegler wrote:
> > On 6/17/06, Juergen Strobel <strobel@secure.at> wrote:

> > >*Advantages*
> > >
> > >-POL, Encapsulation-
> > >
> > >All Strings behave exactly the same everywhere, are predictable,
> > >and do the hard work for their users.
> >
> > Remember: POLS is not an acceptable reason for anything. Matz's m17n
> > Strings would be predictable, too. a + b would be possible if and only
> > if a and b are the same encoding or one of them is "raw" (which would
> > mean that the other is treated as the defined encoding) *or* there is a
> > built-in conversion for them.
>
> Since I probably cannot control which Strings I get from libraries,
> and dont't want to worry which ones I'll have to provide to them, this
> is weaker than my approach in this respect, see my next point.

It's apparent from the explanation above.
You do not have to look at  string encoding or worry which encoding
they are as long as they are compatible (ie iso-8859-1 and utf-8) -
there is a conversion for them. The string methods have to use
(internally) the encoding tag, and you can look if you are interested.
If the  strings are incomatible it is a real problem. Not one created
by the implmentation but one originating form the fact that the
strings cannot be automatically converted from one ecoding to another.
But you can keep all your strings, even if they are in several
incompatible encodings. You are not limited to using just one
encoding.


Michal