From: Juergen Strobel <strobel@...>
Date: 2006-06-29T15:44:10+09:00
Subject: Re: Unicode roadmap?

--VywGB/WGlW4DM4P8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 29, 2006 at 03:43:54AM +0900, Austin Ziegler wrote:
> On 6/28/06, Juergen Strobel <strobel@secure.at> wrote:
> >Any additional complexity here should be offset later, when doing
> >operations on the read data as appropriate for its type.
>=20
> It won't be. All of the complexity of the m17n String will be inside of
> the String, not exposed (by default) to the user. Stop thinking of the
> encoding of a String as something that makes the String a unique object;
> instead it is a lens that gives meaning to the bytes of the String.

Having said lens adds complexity. I'll always have to think of the
data and the lens. You are very absolute in denying this, I wonder
why.

>=20
> >Of course, the first line should raise an exception if file.txt is not
> >utf8 encoded,
>=20
> The internal format of String is not going to be Unicode by default.
> Matz has already said that. I happen to agree with him.

Please stop beating this dead horse. Noone is disputing Matz's right
to implement as he likes.

And this is not about the String per se, in that line of code clearly
something supposed to be UTF8 is read from a file, and if the file
doesn't contain valid UTF8, I'll expect an exception. Not getting that
exception adds complexity to my code, because I'll have to verify it
later on manually, and it may obscure the source of the error if I
forget. Complexity added in both cases.

Prior point proven.

> >this saves extra complexity down the line, and is a real difference
> >between the two. I imagine Bytevector would be implemented with
> >maximum performance and space efficiency in mind, while String is a
> >higher level class streamlined for easy of use.
>=20
> These two items are not mutually exclusive. Think a little more about
> humane design and you'll see that two wholly separate classes require a
> lot more than what you're assuming and would end up in programmers
> making even dumber assumptions than they do today, because they'd think
> they're "protected" during IO because they're getting a String. This is
> not a safe assumption. Ever.
>=20
> The separate byte vector class is needlessly complex and solves exactly
> nothing that isn't already solved in a better way.

Without a prototype, this is speculation at best. Programmers would be
protected by exceptions from invalid String I/O operations. Human
interface design hinges on a lot more and different things than this
one special detail, I can't imagine it will change a lot, and many
ruby programmers aren't that dumb as you make it. This is a red herring.

OT, you should watch whom you call dumb, stupid or foolish here, even
by implication.

That said, I am waiting for M17N as Matz has decided on that, and I
suspect noone else is going to implement anything else for now. But
don't tell me it'll be just perfect for everyone, when discussed use
cases already show it won't be. Matz himself said, that in order to
cater to his own special interest group, he is willing to sacrifice
some convenience for others.

-J=FCrgen

>=20
> -austin
> --=20
> Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
>               * austin@halostatue.ca * http://www.halostatue.ca/feed/
>               * austin@zieglers.ca
>=20
>=20




--=20
 The box said it requires Windows 95 or better so I installed Linux

--VywGB/WGlW4DM4P8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iQEVAwUBRKN2tPy64gyiEfXtAQLiPAgA4Xxmdqax7fHBULHWQ1XfzdkT13o8SX5/
rLHtNzP02sXzEINS2ho2LtJ9zUhG6rqkZjy3WreBWgq23v985+XMU2KEtHOKeMIZ
nYct9cDZ25y3MmzdWiL1dXtz8LUamU3laVwREbAITiMwGUduVUn0/aZg4mxxaucH
LMO6wSTNTqM5lkaHLvn2NM3j8GZyjvf+7PdbHT2HxnyPoCH3cy08uTywDFp1VxD8
bJzBsMhQOVUbfVJg0do4M0hLGpwLeBJG3hZ0ViQYM7m9pUXjTTJ+HfQPanF/CTuz
24jOfIJaAdr1cbIwe1h+fUAOoL8joedPRqwYdDSdbIHawSyVyggVRQ==
=A+9k
-----END PGP SIGNATURE-----

--VywGB/WGlW4DM4P8--