On 2024-02-09 19:01, christoph.thiede@student.hpi.uni-potsdam.de wrote:


This discussion started a while back (last October!) when I was having a problem with Seaside entity tag creation. I thought we pretty much concluded that #asByteArray wasn't a very good method name that had become misused in way too many ways.

As mentioned before, I do not insist on the name #asByteArray, but I would like to have the general functionality under whatever name in the trunk.

-1

Regarding "the general functionality":

As discussed before (I think), there are many ways in which you might want to convert an integer into a sequence of bytes, and there is no such thing as a single correct way to do it. Maybe you want 32 bit twos complement little endian, or maybe you want 48 bit ones complement in network byte order, or maybe you want EBCDIC decimal bytes. You can implement any of these things and a dozen others, but none of them should be named #asByteArray.

Regarding "under whatever name in the trunk":

Just don't. It is very easy to put something into trunk, and it is extremely difficult to get rid of it a few years later. So if there is no real use case and no clear understanding of the functionality, it is best not to add it.

There are other ways to handle this. In FileSystem-Git, Integer>>asByteArray is an extension method, and the method comment explains that it is "copied from Pharo 5". This may not be the preferred method name, but the reason for it is explained and it is kept separate from Squeak trunk. This means that if the method causes problems later on, the reader will know why it is there and maybe what to do about it.

I'm not sure what Tim did to handle the original Seaside issue, but there is a compatibility package called "Grease" for Seaside that is designed to handle dialect-specific differences like this, so that might be a good place to handle "convert an integer to a byte array for Seaside". Maybe it would be the same thing as the Pharo 5 method, or maybe it is something else, but either way these seem like things that are best handled by the external packages (Seaside or FileSystem-Git or whatever).

Dave