I'm working on improving the documentation. I'd like examples of situations
when you'd use one or the other and why...
Also, the FFIOpaqueObject class comment could be fleshed out a bit. Check
out this excerpt:
"this means we always access them through a reference.
Now, we could declare the pointer to the structures, but
then our declarations wouldn't be as close to C as we want."
What would be an example of "declar[ing] the pointer to the structures" and
the resulting declarations that "wouldn't be as close to C as we want"?
There are plenty of cases in C where you do:
struct MyStruct *s;
Buy tou cannot do (or you cannot use):
struct MyStruct s;
This is like that because most modern frameworks use the opaque type as a place to keep state, but to interact with them you use functions. e.g:
MyOpaqueType *ot = newOpaqueType();
opaque_type_someFunction(ot, ���a parameter���);
Then an opaque object would be:
FFIOpaqueObject subclass: #MyOpaqueType.
And you can do an ffi call like this:
self ffiCall: #(void opaque_type_someFunction(MyOpaqueType *ot, char *aString)).
Note the declaration of "MyOpaqueType *ot���
This is how C declaration looks.
We can say that an opaque type is a pointer type with arity 0.
Now, an FFIExternalObject (which should be called FFIExternalPointer), has already an arity of 1.
Which means, if you declare:
FFIExternalObject subclass: #MyOpaqueTypePtr.
The same ffiCall you did before would be:
self ffiCall: #(void opaque_type_someFunction(MyOpaqueTypePtr ot, char *aString)).
Note the declaration without the *��� this is because
FFIExternalObject is already a pointer.