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

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