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
|