Hi Dave,

On Nov 13, 2023, at 9:33 AM, lewis@mail.msen.com wrote:

A Number should not respond to #asByteArray.

Agreed. Ignore my previous reply which was specific to the integers.  More accurately we could say “In general, a Number should not respond to #asByteArray. But for some kinds of number, a byte array representation may make sense.”

There are lots a of possible binary encodings for numbers, which means that there is no such thing as a correct answer to the question of how to represent a number as an array of bytes.


On 2023-11-13 12:53, Taeumel, Marcel via Squeak-dev wrote:

1 asByteArray #[1 0 0 0 0 0 0 0] 
1152921504606846975 asByteArray #[255 255 255 255 255 255 255 15] 
1152921504606846976 asByteArray #[0 0 0 0 0 0 0 16] "Large Positive Int"

Am 13.11.2023 13:33:31 schrieb Marcel <marcel.taeumel@hpi.uni-potsdam.de>:

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 <asqueaker@gmail.com>:

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 <squeak-dev@lists.squeakfoundation.org> 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 <tim@rowledge.org>:

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

> On 2023-10-31, at 7:43 PM, lewis@mail.msen.com 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; tim@rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: NOP: Randomize the PSW and then branch