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.