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.

If you know in advance that your object is e.g. a LargePositiveInteger and if you know that you want to serialize that object into a sequence of bytes, and if you know that each byte should be 8 bits in size, and if you know the endianness of the target byte order representation, and if you know that the desired numeric representation is e.g. twos complement (as opposed to say ones complement) integer, and you know that the register size of the numeric representation is 8 bytes (or 4 bytes, or 2 bytes, or whatever) then you might reasonably want to offer a convenience method to make the happen, Large positive integers are the simple case for which most people will know what to expect from #asByteArray, so offering this as a convenience method makes sense. For other kinds of numbers (or objects) it does not make sense and should not be implemented.

Dave

On 2023-10-30 19:01, Tim Rowledge wrote:

Whilst testing out Seaside in the 6.1 trunk image we discovered that LargePositiveInteger needs an #asByteArray method to enable the entity tag method to provide all that nice formatting stuff.

For the specific case of LPI it's trivial "self as: ByteArray" works fine and sure, maybe it could be optimised.

However, there is actual usage of #asByteArray in the main image that appears to be unsatisfied. For example, Magnitude>>#putOn: for binary streams. It appears no subclass of Magnitude implements #asByteArray, which seems unfortunate.#putOn: is used a fair bit in writing to streams. There's also some clashing with potentially important behaviour where collections of (very)smallintegers can be converted to ByteArrays so long as all the numeric values are <255. If we were to make an #asByteArray for SmallInteger that produced up to 8 bytes, how might that affect some of these usages? And what is a good byte array representation of a LargeNegativeInteger? And should every conversion be reversible?

tim
--
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: EF: Emulate Fireworks