> On 28 Nov 2017, at 16:25, Ben Coman <b...@openinworld.com> wrote: > > I just bumped into... > FFUInt64>>basicHandle: aHandle at: index > ^ aHandle signedLongLongAt: index
that’s probably a bug :) Esteban > > and I'm curious why #unsignedLongLongAt: is not used. > Seems I had the same question a year ago... > > On 1 September 2016 at 22:09, Ben Coman <b...@openinworld.com> wrote: >> I'm looking through the keyhole at something new to me, so maybe this >> is off base, but looking at the inheritance hierarchy... >> >> FFIIntegerType >> FFIUint16 >> FFIUint16 >> FFIUInt32 >> FFIInt32 >> FFIUint64 >> FFIInt64 >> FFIUint8 >> FFIInt8 >> >> I'm curious... why the all the Ints inherit from the UInts? >> >> Each of those classes has the same two methods #basicHandle:at: and >> #basicHandle:at:put. So the Int subclasses fully override the >> superclass methods. So there in no inherited behaviour on the instance >> side. >> >> On the class side, I see #externalTypeSize is inherited by the Ints, >> but evaluating... >> FFIIntegerType allSubclasses collect: [ :class | >> class externalType byteSize -> class externalTypeSize ] >> produces... >> 4->4 >> 2->2 >> 4->4 >> 8->8 >> 1->1 >> 2->2 >> 4->4 >> 8->8 >> 1->1 >> >> So naively the extra inheritance level seems unnecessary >> and perhaps having... >> FFIIntegerType class >> externalTypeSize >> ^ self externalType byteSize >> >> would allow the hierarchy to be flattened. Maybe not a great benefit, >> except to avoid the next person wondering the same thing :P > > Perhaps its significantly faster to have the method directly return > the integer rather than do a few more message sends (??) > > cheers -ben > >> >> >> Also, it is surprising that that FFUInt64 uses #signedLongLongAt: >> rather than #unsignedLongLongAt: . This seems on-purpose rather than >> accidental since its inherited by FFIInt64, so it seems there is >> something interesting to learn here that would benefit a method >> comment. >> >> cheers -ben >
