> On 29.07.2017, at 21:15, tim Rowledge <tim at rowledge.org> wrote:
> 
> We recently changed ByteArray>at:put: to remove the backup conversion of the value to integer, for what seemed like decent reasons.
> 
> It’s broken my WeatherStation code a little because there are places where I use
> {my byte stream} nextPutAll: (aString squeakToUtf8)
> or similar. #squeakToUtf8 returns a bytestring, and of course when the #nextPutAll: loop does its thing each character is pulled out as a Character (even though we know at this point it’s a byte value) - and we’ve just made it impossible to stick a character into a byte array.
> 
> Clearly I could fix it reasonably trivially with a few #asByteArray type messages scattered around but it feels a bit tacky somehow. I see some faintly similar code with plausibly similar issues in WebSocket classes too, which would need some care. Not that I can see a lot of usage of that code…
> 
> Performance isn’t a colossal issue for MQTT packets but it just rankles a bit to have a known byte valued string and then have to convert it to write it into a byte valued stream collection. KnowWhadIMean? 
> 

Underlying questions:
- does an utf8 encoded string contain unicode-valued characters?
-> is an utf8-encoded string a string after all?

I'd suggest no out of purity but I'll expect yes from other out of practicality.

Best regards
	-Tobias

> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Never write software that anthropomorphizes the machine. They hate that.
> 
> 
>