Hi All,
in porting the ClipboardExtendedPlugin to Windows and starting using it I want to do UTF-16 => string conversion on ByteArray. The innards of textConverter>>decodeString: et al are specific for characters for no good reason I can see. If I don't break the tests does anyone object my adding this polymorphism? _,,,^..^,,,_ best, Eliot
Hi Eliot,
My gut feeling tells me: please go right ahead. I find it irritating how some ByteStrings are really just bytes with the "wrong" type anyway. That you can look at strings of bytes through those two different lenses always reminds me of C and that does not feel well. ;-)
Besides, if you process UTF-16 bytes, why not use DoubleByteArray?
Kind regards, Jakob
Am Mo., 21. Nov. 2022 um 21:18 Uhr schrieb Eliot Miranda < eliot.miranda@gmail.com>:
Hi All,
in porting the ClipboardExtendedPlugin to Windows and starting using
it I want to do UTF-16 => string conversion on ByteArray. The innards of textConverter>>decodeString: et al are specific for characters for no good reason I can see. If I don't break the tests does anyone object my adding this polymorphism? _,,,^..^,,,_ best, Eliot
On Mon, Nov 21, 2022 at 1:05 PM Jakob Reschke jakres+squeak@gmail.com wrote:
Hi Eliot,
My gut feeling tells me: please go right ahead. I find it irritating how some ByteStrings are really just bytes with the "wrong" type anyway. That you can look at strings of bytes through those two different lenses always reminds me of C and that does not feel well. ;-)
+1
Besides, if you process UTF-16 bytes, why not use DoubleByteArray?
Godo question and I'm not entirely sure, but I think it comes down to endianness. Accessing a UTF-16 stream as bytes allows one to support either endianness. Using DoubleByteArray makes it straight-forward to use the platform's endianness, and more difficult to use the other endianness.
Kind regards, Jakob
Am Mo., 21. Nov. 2022 um 21:18 Uhr schrieb Eliot Miranda < eliot.miranda@gmail.com>:
Hi All,
in porting the ClipboardExtendedPlugin to Windows and starting using
it I want to do UTF-16 => string conversion on ByteArray. The innards of textConverter>>decodeString: et al are specific for characters for no good reason I can see. If I don't break the tests does anyone object my adding this polymorphism? _,,,^..^,,,_ best, Eliot
Hi
On 21. Nov 2022, at 21:17, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
in porting the ClipboardExtendedPlugin to Windows and starting using it I want to do UTF-16 => string conversion on ByteArray. The innards of textConverter>>decodeString: et al are specific for characters for no good reason I can see. If I don't break the tests does anyone object my adding this polymorphism?
_,,,^..^,,,_ best, Eliot
I often have the "make it right" glasses on. I know thats not really pragmatic, but hear me out a second:
_Decoding_ should always work bytes/number -> Characters/string _encoding_ should always work characters/strings -> bytes/numbers
I know that's not very light hearted.
That said, making TextConverter consume bytes is a good thing in my book. I don't think #decodeString is a good message name when it can _consume_ strings but only when it can _produce_ strings. But that was not the question :D
Best regards -Tobias
squeak-dev@lists.squeakfoundation.org