IMO, it absolutely makes sense to not require specifying that in cases where the other side is Squeak.  Particularly when working with a set of cryptographic primitives that support String, ByteArray or Integer scalars interchangeably, not having to worry about the internal byte order of ByteArray's, other than it be consistent with the other side, which a default would cover, is nice.

Therefore, IMO there's no reason to force the cognitive burden of byte order by excluding #asByteArray, but instead provide #asByteArray: aBoolean, which #asByteArray can call with a default choice.

On Fri, Nov 3, 2023 at 5:36 AM Marcel Taeumel via Squeak-dev <> wrote:
Hmm... not sure that #asByteArray makes sense without specifying encoding rules such as little-vs-big-endian, signed-vs-unsigned, max-num-bytes, etc ... hmm....


Am 01.11.2023 04:33:31 schrieb Tim Rowledge <>:

An interesting thought. Kinda suggests we should get rid of the usages like #putOn:

> On 2023-10-31, at 7:43 PM, wrote:
> It does not generally make sense for a number, or any other kind of object, to know how to represent itself as a byte array.

I see your point about the range of plausible options.

tim Rowledge;;
Strange OpCodes: NOP: Randomize the PSW and then branch