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

[Eliot Miranda]

On Fri, Dec 11, 2015 at 11:05 AM, Colin Putney <colin at wiresong.com> wrote:

>
>
> 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.
>

Ah, thanks for the clarification.  Unwise of me to read complex emails on
the phone :-).  Letter box problem.   I agree.  ICU should be steered clear
of at all costs.


> Colin
>
>
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151211/8b17600a/attachment.htm