Must be a thing about European "guys" ...

<quote>

- ByteString is needed for most european/occidental people who don't care about internationalization and should stay because Pharo is an european/english based system , also not to break existing code
(again will be transparent to most users for same reason).

</unquote>

Of all reasons to retain ByteString, let's hope this one is not listed, lest we appear ridiculous in our threads.

r



On 26 September 2014 18:22, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
Le 26/09/2014 20:47, stepharo a ��crit :
I'm not expert and I would like to know what people think.
But I think that we should consider

�� �� ��- the impact of spur new object format. I would like to have
unicode and clean the leadChar

Stef


Just to start a new thread about that, because it deserves it
and also some people might appreciate :)
(was in: "Ridiculous we are").

I may not be the most qualified to state on that but I give my 2c
(this is a community isn't it ? please do not flame...)

As Sven said, the situation is not so bad (quite good in fact): Pharo has true unicode built-in support with WideString and encoders (great job, IMHO this part of Zn components should be in the base system
or in an internationalization package�� not hidden in an htpp components package).
- encoding support has to be in the system : ZnEncoders(?) for utf8, unicode and other encoders for locale support because of existing system basis, web (utf8) and internationalization.
- this will be transparent: Smalltalk is a typeless langage, one do not have to specify String type (ByteString or WideString)
- Spur new character encoding is very interesting (in alpha stage now) and will be transparent for the same reason (though I'm still wondering of the 32bits/64 bits encoding on a 64 bits vm?).
- ByteString is needed for most european/occidental people who don't care about internationalization and should stay because Pharo is an european/english based system , also not to break existing code
(again will be transparent to most users for same reason).
- some parts of the system seems to be not "WideString/unicode aware" :
Pasting a Greek string in a workspace shows hieroglyphs (editors? morph?), but GT Inspector display is ok.
Font plugin seems to require little work : uses fopen instead of _wfopen (utf16 version) on windows and needs utf8 convertion on unix.
may be a check with File plugin (and other system related plugins) is also needed?

In short, some little additionnal work but a very good basis.
(but what is leadChar about?)

Regards,

Alain