<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi all --<div class="mb_sig"></div>
                                        <div><br></div><div>Interesting recent share via the Pharo mailing list:</div><div><a href="https://github.com/svenvc/UTF8String"><span style="font-size: 10pt">https://github.com/svenvc/UTF8String</span></a><br></div><div><br></div><div>It's good to see that one can implement the concept in Smalltalk without needing extra VM support. Then again, our UTF8TextConverter does this as well. :-)</div><div><br></div><div>I think an implementation of Utf8String should subclass from String (instead of Object) as it would be the third among the two existing encodings, namely ByteString and WideString.</div><div><br></div><div>In general, here are some thoughts on having Utf8String in general:</div><div><br></div><div>Pro:</div><div>+ The concept of "strings are collections of characters" can still hold</div><div>+ Special FFI type for such utf8 strings can help writing more robust code</div><div><br></div><div>Con:</div><div>- User data beyond 21-bit for Unicode code points would not be possible (e.g. #leadingChar)</div><div><br></div><div><span style="font-size: 10pt">Best,</span><br></div><div>Marcel</div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 09.03.2022 22:41:54 schrieb Jakob Reschke <jakres+squeak@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi,<br><br>I think the byte-wise collation algorithm implemented in primitive 158<br>and primitiveCompareString cannot fully work with multi-byte<br>encodings:<br><br>a \x61<br>b \x62<br>c \x63<br>ß \xc3\x9f<br>ä \xc3\xa4<br><br>ä and ß both start with byte \xc3 when UTF-8-encoded.<br>Let the collation rules be a = ä < b < c < ß.<br>With the algorithm you cannot have ä < b and b < ß at the same time<br>because the \xc3 can only be before \x62 or after \x62, but not both.<br>(Setting (order at: \xc3) = (order at: \x62) is also not an option<br>because you could not satisfy all of b < c, ä < c and c < ß.)<br>Anyway, comparing ßc with ac would not work correctly because the<br>second byte of the ß gets compared with the letter c of the other<br>string.<br><br>Unrelated to the encoding, the algorithm also cannot account for<br>collation rules involving more than one character, like ß = ss.<br><br>Kind regards,<br>Jakob<br><br>Am Mi., 9. März 2022 um 17:27 Uhr schrieb Marcel Taeumel<br><marcel.taeumel@hpi.de>:<br>><br>> Hi there --<br>><br>> Did somebody already put some thought in the pros and cons of having an Utf8String (and Utf8Symbol) regarding:<br>><br>> - #compareWith:collated: (primitive 158)<br>> - #compare:with:collated: (#primitiveCompareString in #MiscPrimitivePlugin)<br>> - #at:(put:) (primitives 63 and 64)<br>><br>> Our current distinction between ByteString and WideString allows for fast #at:(put:) access but might be slow when comparing ByteString with WideString.<br>><br>> Some external libraries (e.g. via FFI) might even expect Utf8 encoded strings as input. At the moment, we would have to put Utf8TextConverter to work explicitely.<br>><br>> No call for action here. Just a survey. :-)<br>><br>> Best,<br>> Marcel<br>><br><br></marcel.taeumel@hpi.de></div></blockquote></div>