On Mon, Sep 15, 2014 at 3:01 AM, Nick Wellnhofer <[email protected]> wrote:
> Originally, I didn't think of it as a cast operation but more like a
> constructor for interface objects. It would be nice if the API would support
> an implementation using interface objects that are allocated separately.
That's possible under the current proposal by combining an INCREF and a cast,
right?
Let's also consider the possibility of representing interface objects using a
two-word struct, like Go.
typedef struct Comparer {
cfish_Obj *obj;
cfish_Interface *itable;
} Comparer;
static inline struct Comparer
toCOMPARER(void *vself) {
Comparer comparer;
comparer.obj = (Obj*)vself;
comparer.itable = fast_find_itable(comparer.obj);
if (comparer.itable == NULL) {
// slow lookup ...
}
return comparer;
}
static inline int32_t
Comparer_Compare_To(Comparer self, Obj *other) {
char *ptr = (char*)self.itable;
Comparer_Compare_To_t method
= (Comparer_Compare_To_t)(ptr + Comparer_Compare_To_OFFSET);
return method(self.obj, other);
}
int32_t
Foo_Compare_To_IMP(Foo *self, Obj *other) {
...
}
This more or less works for invocations, but also means that you can't use the
interface object in any place we would ordinarily use an `Obj*`.
int
S_compare(void *va, void *vb) {
Comparer *a = *(Comparer*)va;
Comparer *b = *(Comparer*)vb;
return Comparer_Compare_To(*a, b->obj); // complicated.
}
So, the only benefit is slightly streamlined interface method dispatch, but it
comes at the cost of making the C API for using interface objects more
cumbersome.
It also makes it more difficult to convert to host objects and back. For
instance, we can't store a two-word struct in a Perl SV's IV slot.
That doesn't seem worthwhile. It might be different if the compiler were able
to perform conversions implicitly as with Go's compiler, but even then
interoperability would suffer -- and Clownfish is all about interoperability.
Marvin Humphrey
