Wouldn't the best thing (at least for now) be to just accept the string how ever it comes in and not convert it unless needed? Perhaps make the different classes specific and the application designer can decide for his application. The UTF8String should probably not have an #at: message, so that users know they have to convert the string if they want random access to it.
> From:
[hidden email]> Date: Sun, 10 Jun 2007 09:54:55 -0700
> To:
[hidden email]> Subject: Re: UTF8 Squeak
>
>
> On Jun 10, 2007, at 3:55 AM, Janko Mivšek wrote:
>
> > I think that this way we can achieve most efficient yet fast
> > support for all languages on that world. Because of fixed length
> > those strings are also easy to manipulate contrary to variable
> > length UTF-8 ones.
>
> "Most efficient yet fast" is a matter of perspective. For the apps I
> work on, UTF-8 is better than your scheme because space efficiency is
> more important than random access, and time spent encoding and
> decoding UTF-8 would dwarf time spent scanning for random access.
>
> As soon as you try to support more than 256 characters, there are
> trade-offs to be made. The "ideal" solution depends on your
> application. How important is memory efficiency vs. space efficiency?
> How about stream processing vs random access? What format is your
> input and output? Which characters do you need to support, and how
> many of them are there?
>
> A good string library will be flexible enough to allow its users to
> make those trade-offs according to the needs of the application.
>
> > Conversion to/form UTF-8 could probably also be simpler with help
> > of bit arithmetic algorithms, which would be tailored differently
> > for each of proposed three string subclasses above.
>
> Yes, a couple of well designed primitives would help quite a bit.
>
> Colin
Play free games, earn tickets, get cool prizes! Join Live Search Club.
Join Live Search Club!
Locked
