Hi Guille, On Tue, Jan 3, 2017 at 1:40 PM, Guillermo Polito <[email protected]> wrote: > > On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <[email protected]> > wrote: >> >> On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen < >> [email protected]> 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
