FFIIntegerTypes inheritance hierarchy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

FFIIntegerTypes inheritance hierarchy

Ben Coman
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


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

Reply | Threaded
Open this post in threaded view
|

Re: FFIIntegerTypes inheritance hierarchy

Ben Coman
I just bumped into...
    FFUInt64>>basicHandle: aHandle at: index
        ^ aHandle signedLongLongAt: index

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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: FFIIntegerTypes inheritance hierarchy

EstebanLM


> On 28 Nov 2017, at 16:25, Ben Coman <[hidden email]> 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 <[hidden email]> 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
>