The version copied from Pharo 5 simply turns -1 into #[1].

So, in Pharo, I should expect:

    -1 asByteArray asInteger = -1    "false"

I mean, how is that not a bug?
 
So if yours
raises an error Chris, the different variants that are around already
have different behavior.

True, but is that an issue?  If an external framework brings in its own #asByteArray as a normal override, it should work with no changes.

I just wonder whether it's better to continue to let the new variants proliferate, or establish a baseline implementation.

Best,
  Chris
 

For what it's worth, FileSystem-Git just seems to need it in two
methods involved with Git pack file writing. One of them seems to have
no senders... The other one uses asByteArray to collect the bytes of
all the sha1 hashes. Hmm, this may have a bug if one hash starts with
'00' and thus the underlying LargePositiveInteger only has 19 bytes.
That might even be the explanation of bug #1
https://github.com/hpi-swa/Squot/issues/1 :-P

Am Sa., 10. Feb. 2024 um 16:58 Uhr schrieb Chris Muller <asqueaker@gmail.com>:
>
> On Fri, Feb 9, 2024 at 11:55 PM Vanessa Freudenberg <vanessa@codefrau.net> wrote:
>>
>> On Fri, Feb 9, 2024 at 9:41 PM Chris Muller <asqueaker@gmail.com> wrote:
>>>
>>> I feel that Christoph's request kinda shows us that there is a desire for a universal, friendly, #asByteArray and #fromByteArray: pair(s) that "just work" together for the cases when only compatibility matters, and not the particular byte order, and is therefore worthy of consideration.
>>
>>
>> Wouldn't that imply that #asByteArray and #fromByteArray: would have to be the inverse of each other? Currently that's not possible because, as stated before, at least for large integers #asByteArray currently answers the same array for different numbers.
>
>
> ByteArray's only support element values between 0 and 255.  Attempting to convert -1 to a ByteArray rightly produces an error, as I thought you mentioned before.
>