> On 22 May 2020, at 15:25, Esteban Lorenzano <esteba...@netc.eu> wrote:
> 
> 
>> On 22 May 2020, at 15:07, Ben Coman <b...@openinworld.com 
>> <mailto:b...@openinworld.com>> wrote:
>> 
>> 
>> 
>> On Fri, 22 May 2020 at 15:25, Esteban Lorenzano <esteba...@netc.eu 
>> <mailto:esteba...@netc.eu>> wrote:
>>> On 22 May 2020, at 04:24, Sean P. DeNigris <s...@clipperadams.com 
>>> <mailto:s...@clipperadams.com>> wrote:
>>> 
>>> Esteban Lorenzano wrote
>>>> The class comments are not clear?
>>> 
>>> Maybe it's me ;-)
>> 
>> 
>> No. I struggled with this also, and still don't have it fully grasped.  I 
>> could follow Eteban's advice in a particular case I asked about, but still 
>> feel hard to reason about next time. 
>> http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.html
>>  
>> <http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.html>
>>  
>> http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity-td4917236.html
>>  
>> <http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity-td4917236.html>
>>  
>>  
>>> 
>>> 
>>> Esteban Lorenzano wrote
>>>> Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type 
>>>> <https://en.wikipedia.org/wiki/Opaque_data_type>
>>>> &lt;https://en.wikipedia.org/wiki/Opaque_data_type&gt 
>>>> <https://en.wikipedia.org/wiki/Opaque_data_type&gt>;
>>>> External object = a pointer to something. 
>>> 
>>> For example, why is ObjCClass a subclass of FFIExternalObject instead of
>>> FFIOpaqueObject when the docs say that a "Class [is] An opaque type that
>>> represents an Objective-C class"? Also, is the distinction just conceptual?
>>> I don't see what either class "buys" you in behavior since they are siblings
>>> that both pretty much have no methods. 
>> 
>> 
>> This is because ObjCClass = SomeOpaqueStructurePointer (is already a 
>> pointer), same as ObjCSelector and ObjCMethod.
>> Difference is subtle, because is just a different way of representing the 
>> same. 
>> 
>> The easiest way I have to explain is: 
>> 
>> As a prelude to my next comment, how does "External" distinguish between the 
>> two case?
>> Aren't both cases dealing with external C data? 
>> 
>> You use an OpaqueObject when you will refer to "the opaque type" in calls 
>> as:  someFunction(opaqueobject *someArg).
>> You use an ExternalObject when you will refer to "the opaque type" in calls 
>> as: someFunction(externalobject someArg).
>> 
>> That makes the distinction really clear.  So if now IIUC, both cases deal 
>> with "opaque types" 
>> with the *only* difference between the two being the arity?
>> Then I propose the following naming would be more intention revealing...
>> 
>> OpaqueObject when you will refer to "the opaque type" in calls as:  
>> someFunction(opaqueobject *someArg).
>> OpaquePointer when you will refer to "the opaque type" in calls as: 
>> someFunction(opaquepointer someArg).  
>> 
>> 
>> And to test my new understanding, the matching typdefs and FFI calls would 
>> be...
>> 
>> OPAQUE OBJECT
>> -  typedef MyOpaqueType opaqueobject.
>> -  int someFunction(opaqueobject *someArg) 
>> 
>> -  FFIOpaqueObject subclass: #MyOpaqueType.
>> -  self ffiCall: #(int someFunction( MyOpaqueType *ot ) ).
>> - opaque type has arity 0, so FFI needs to take a pointer to it  
>>  
>> OPAQUE POINTER
>> -  typedef MyOpaqueObject *opaquepointer.
>> -  int someFunction(opaquepointer someArg) 
>> 
>> -  FFIOpaquePointer subclass: # MyOpaqueType.
>> -  self ffiCall: #(int someFunction( MyOpaqueType ot ) ).
>> - opaque type has arity of 1,  so FFI uses it directly     
>> 
>> The latter FFI call is without the *… because FFIOpaquePointer is already a 
>> pointer. 
>> In practice, both FFI calls are identical, and you use the one that matches 
>> the C header definitions.
>> 
>> 
>> ...or maybe I still don't get it.
> 
> No, you got it :)
> Part of the confusion is the horribly bad name that FFIExternalObject has :/
> Other part is my inability to explain it ;)
> 
> But yes, this is all as you say.
> If someone wants to do a PR changing the names and maybe enhancing my 
> comments… it would be nice :D
Of course keeping the old names as deprecated! ;)

> 
> Esteban
> 
>> 
>>  cheers -ben
> 

Reply via email to