[Vm-dev] Re: [squeak-dev] Re: [Pharo-dev] Unicode Support

Colin Putney colin at wiresong.com
Fri Dec 11 19:05:35 UTC 2015


On Fri, Dec 11, 2015 at 1:29 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> > For my part, the reason I think we ought to implement it *in*
> > Smalltalk is ...  this is the String class of the new age.  I want
> > Smalltalk to be handle Strings as native objects.
>
> There's little if any difference in convenience of use between an Array of
> characters and a bits array with the string at:/at:put: primitives since
> both require at:/at:put: to access, but the latter is (efficiently) type
> checked (by the VM), whereas there's nothing to prevent storing other than
> characters in the Areay unless one introduces the overhead of skier
> explicit type checks  in Smalltalk, and the Areay starts life as a sequence
> of nils (invalid until every element is set to a character) whereas the
> bits representation begins fully initialized with 0 asCharacter.  So
> there's nothing more "natively objecty" about the Array.  Smalltalk objects
> hide their representation from clients and externally they behave the same,
> except for space and time.
>

I think Euan was referring to the Gemstone strategy of storing the string
content as bits, then calling into ICU (a C++ library for Unicode
processing) to manipulate them. So he's saying sure, store the string data
as bits, but write Smalltalk code to sort them, render on screen etc.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151211/32660794/attachment-0001.htm


More information about the Vm-dev mailing list