Unicode support

Peter Smet peter.smet at flinders.edu.au
Tue Sep 21 23:34:15 UTC 1999


From: agree at carltonfields.com <agree at carltonfields.com>


>We already have the most general string implementation possible.  It's
called Array, and its very, very fast and well-implemented.  What is it that
makes a String different from an Array?  Let's define the protocol and a
class hierarchy, and see where we should be going, if anywhere.
>
>> Using a "generic object oriented > character based
>> string class" is the most general string object design > possible and has
>> many benefits.
>
>Once again, how is it different from Class array?  What do we need to add
to make it happen?
>


I dont understand how an Array is useful as a general String. They are both
Collections, and that is about it.
To quote from one of your earlier posts:

:You can get a collection of tokens using String>>findTokens:  You can
:also get a line from a string using String>>lineNumber:  There are a
:gaZillion cool ways to manipulate string in class String, which you
:can peruse with the DoIt:

Array cant and shouldnt do any of these things (should it?)
Or is this your point - what protocol differentiates Strings from Arrays?

Maybe the only responsibility of the general StringClass should be as a
Convertor:
String>>
as: aCharacterSet
asUnicode
asAscii
etc.....

The reason I say this is that a common protocol for all Strings is a tough
ask.
As people point out, even asUppercase won't hold for many languages.
You may end up with a restricted and fairly useless protocol.
With the 'asUnicode' approach, the client determines which protocol will
be used to communicate with Strings. So a String has many possible
interfaces (protocols), and the client chooses an appropriate interface
by which to manipulate the String.

Peter





More information about the Squeak-dev mailing list