Hi Dave, 

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.

I appreciate this point, however, it's also true that often it isn't the particular internal representation itself that the developer cares about, only that the producing function is compatible with the consuming function.

You can implement any of these things and a dozen others, but none of them should be named #asByteArray.

Which is why being forced to always have to "look up" the other side's otherwise irrelevant byte order, just to be able to write this side correctly, feels like an unnecessary burden in those situations.

I certainly agree that all the API specifying the byte order should exist and be the primary API, but 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.

A seeming irony about it is, not defining it creates a sort of feedback that supports the critique that there might be different, incompatible definitions, whereas, defining it would actually allow that argument to simply evaporate...