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