Hi Guille,

On Tue, Jan 3, 2017 at 1:40 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:

On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

[snip]

��

2) Accessor remains the same, but all references in the base image has been rewritten to use EndianDetector directly...
2) Would not Smalltalk platform be a reasonable place to put this responsiblity, letting it use an EndianDetector behind the scenes? Both the preexisting #endianness, as well as the new #isLittleEndian and #isBigEndian?

Here I am not sure of agreeing.

Going through Smalltalk is evil.

Maybe asking the platform is better, to hide the "EndianDetector".

+1.�� EndianDetector is a monstrosity.

Ok, EndianDetector is maybe an ugly name.

No, that's not the reason this is a monstrosity.�� Extracting one method into a class of its own, a method that answers something trivial, that as Hwnrik points out is logically to do with Smalltalk platform, that's what's a monstrosity.�� I could care less what its called.�� But it gratuitously broke lots of code that used it in a very ugly way while adding a large overhead for trivial functionality.�� It's a monstrosity.

But it has a reason to be. Before, to test endianess the system used a Bitmap. And we wanted a standalone class that we could use whether Bitmap is there or not (by becoming an instance of a float into a bitmap or so... I don't remember the details).

Yeah, well, there's a VM parameter, there are no end of ways to compute it, but the point is, it can be a single method on Smalltalk platform not a whole class.

_,,,^..^,,,_

best,��Eliot