On Jun 20, 2015, at 02:21 , Marvin Humphrey <[email protected]> wrote:
> 
> Instead, it may be that C#/Java-style explicit interfaces are the lowest
> common denominator.  (I'd like to think we could also add the feature of
> default methods to that.)

> Well, we need some technique for customizing behaviors from the host.  Right
> now that's subtyping Clownfish classes from the host.  I would be excited
> about supporting interface polymorphism instead.

Yes, I thought we already agreed on that :)

Here’s a implementation sketch for Go:

    https://github.com/nwellnhof/cfish_interfaces

On the Clownfish side, interface objects are implemented as a struct that is 
passed by value. This struct is a pair of a Clownfish Obj and a pointer to an 
ITable containing the interface method pointers. An alternative is the approach 
inspired by C++ that I originally mentioned in CLOWNFISH-12.

There’s a new class HostObj wrapping a host object on the Clownfish side. 
Implementing interfaces as tuples makes it possible to use a single class for 
host objects. With the C++ approach, we’d need a separate class for each 
interface.

Clownfish interface objects are converted to Go by storing a pointer to a Go 
conversion function in the ITable. This is a bit hairy but should be very fast. 
The conversion is a lot easier in dynamically typed languages where we can 
simply pass the Clownfish Obj.

I also implemented a simple object registry to pass Go objects safely to C.

The biggest problem I’m facing is the conversion of wrapped Clownfish Objs to 
Clownfish interface objects on the host language side. With Go, I’m currently 
using a conversion method added to each interface. This is very efficient but 
it requires a bit of boilerplate for pure Go interfaces and it’s not directly 
portable to dynamically typed languages. It would be great if this could be 
solved on the Clownfish side. But I couldn’t find a solution that doesn’t 
require an expensive lookup.

It should also be possible to support default methods. This complicates things 
a little and it might require boilerplate in languages that don’t have native 
support like Go or Java 7.

Nick

Reply via email to