> 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> >>> <https://en.wikipedia.org/wiki/Opaque_data_type> >>> <https://en.wikipedia.org/wiki/Opaque_data_type>>; >>> 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 Esteban > > cheers -ben
