[Cuis-dev] UnicodeString coercion

Juan Vuletich juan at cuis.st
Thu Jul 2 07:49:15 PDT 2026


And what you actually want is most likely #asUtf8BytesOrByteString, 
#asUtf8BytesOrByteStringOrByteArray to properly handle Unicode. That of 
course depends on whether the apis you're calling can handle UTF-8.

Besides, 'abc' is an instance of String. You get a UnicodeString when 
you go beyond ASCII. Most apis prefer UTF-8 in that case.

Cheers,

On 2026-07-01 1:59 PM, Juan Vuletich via Cuis-dev wrote:
>
> Well, that boat sailed a long time ago.
>
> The interoperability between (Byte)String and UnicodeString does 
> exactly the same as interoperability between 
> SmallInteger/LargeInteger/Fraction/Float. With numbers, this only 
> matters when dealing with the external world, where you need to ensure 
> you're using the required primitive type, and not what Smalltalk 
> choses for you. Same here. #asByteString to the rescue.
>
> See 
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/Papers/2022-11-UnicodeSupportInCuisSmalltalk.pdf
>
> Hope this helps,
>
> On 2026-07-01 11:59 AM, Phil B via Cuis-dev wrote:
>> Sorry... forgot to reply all.
>>
>> To put it more succinctly: rather than assume that anywhere you 
>> have a string/stream it's just as good to substitute a Unicode 
>> string/stream, it really seems like it should be opt-in via 
>> #asUnicodeString or #asUniFileStream for coercion or explicit at 
>> instance creation time.  That makes the contract clear and you don't 
>> get something other than what you want/need.
>>
>> On Wed, Jul 1, 2026 at 11:52 AM Phil B <pbpublist at gmail.com> wrote:
>>
>>     I hear what you're saying but that assumption breaks a lot of
>>     code.  They are *similar* to String, but they are actually very
>>     different creatures and only superficially protocol compatible.
>>     (i.e. you often cannot substitute a UnicodeString for a String
>>     without severely breaking things... even when 'String' is nowhere
>>     in the source code that breaks)  I have had to ugly up a lot of
>>     code to get out of the implicit opt-in to Unicode that Cuis has
>>     done on this front.[1] Please don't rename String... that would
>>     make things 100x worse.
>>
>>     [1] i.e. 'where the hell did that UnicodeString come from?' when
>>     I didn't want it... usually when dealing with a DNU error
>>     dialog.  Even when I resolve the DNU, the breakage often
>>     continues on down the chain because you can't just substitute
>>     UnicodeString for String when you're dealing with FFI, web APIs,
>>     file formats etc.
>>
>>     On Wed, Jul 1, 2026 at 11:16 AM Juan Vuletich <juan at cuis.st> wrote:
>>
>>         Hi Phil,
>>
>>         On 2026-07-01 10:27 AM, Phil B via Cuis-dev wrote:
>>         > Is there a reason UnicodeString asString returns self
>>         rather than a
>>         > String?
>>         >
>>         Yes. UnicodeStrings are conceptually Strings. Perhaps we'd
>>         rename String
>>         as ByteString, and CharacterSequence as String.
>>
>>         In any case, just use #asByteString that does what you want.
>>
>>         Cheers,
>>
>>         -- 
>>         Juan Vuletich
>>         www.cuis.st <http://www.cuis.st>
>>         github.com/jvuletich <http://github.com/jvuletich>
>>         researchgate.net/profile/Juan-Vuletich
>>         <http://researchgate.net/profile/Juan-Vuletich>
>>         independent.academia.edu/JuanVuletich
>>         <http://independent.academia.edu/JuanVuletich>
>>         patents.justia.com/inventor/juan-manuel-vuletich
>>         <http://patents.justia.com/inventor/juan-manuel-vuletich>
>>
>>
> -- 
> Juan Vuletich
> www.cuis.st
> github.com/jvuletich
> researchgate.net/profile/Juan-Vuletich
> independent.academia.edu/JuanVuletich
> patents.justia.com/inventor/juan-manuel-vuletich
>
-- 
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260702/5c8fd16b/attachment-0001.htm>


More information about the Cuis-dev mailing list