So, maybe all variable-byte subclasses then?

Just wondering that, when working with integers, this would work for LPI but not for small integers...

How would we implement #asByteArray in SmallInteger? Like this?

| result ws |
result := ByteArray new: (ws := Smalltalk wordSize).
ws = 4
ifTrue: [result longAt: 1 put: self bigEndian: Smalltalk endianness == #big]
ifFalse: [result long64At: 1 put: self bigEndian: Smalltalk endianness == #big].
^ result


Am 11.11.2023 00:15:55 schrieb Chris Muller <>:

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