[
https://issues.apache.org/jira/browse/CLOWNFISH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583460#comment-14583460
]
Nick Wellnhofer commented on CLOWNFISH-12:
------------------------------------------
Yes, it should work for Rust. We'd probably need an interface method like `PTR`
that returns the pointer to a Clownfish object, possibly creating a proxy
object for native Rust types. This method must be implemented by every Rust
interface that is used with Clownfish. But the implementation can be
auto-generated.
My analysis above is a bit flawed. We could actually support Go-style
interfaces without type introspection. A host language with any kind of
interface support could simply define a host language interface for every
Clownfish interface. The actual problem with Go-style interfaces is that any
Clownfish class might implement an interface. In a class from an unrelated
parcel, we don't know at compile time which interfaces it implements.
So an interface method argument could be either a host language interface
object or any Clownfish object. It should be possible to use some kind of type
that can hold any of these objects. But it would be cumbersome and
non-idiomatic to use.
> Clownfish interfaces
> --------------------
>
> Key: CLOWNFISH-12
> URL: https://issues.apache.org/jira/browse/CLOWNFISH-12
> Project: Apache Lucy-Clownfish
> Issue Type: New Feature
> Components: Core
> Reporter: Nick Wellnhofer
> Priority: Minor
>
> Java-style interfaces would be a nice feature for Clownfish. Here's a sketch
> of how it could be implemented. It's basically an adaption of the technique
> described by Bjarne Stroustrup in his paper [Multiple Inheritance for
> C++|http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.4735].
> If a subclass implements an interface, an additional instance variable
> pointing to an interface method table is created. A pointer to this instance
> variable represents an interface reference. The interface method table
> contains
> * the offset of the pointer to the interface method table from the start of
> the object.
> * a variable length array of method pointers to the implementations of the
> interface's methods.
> * optionally a pointer to an Interface object for introspection.
> Every subclass/interface combination needs a separate interface method table.
> Subclasses that don't override any of the interface methods of a parent class
> can reuse the parent class's table.
> The memory layout would look like this:
> {noformat}
> object
> +--------+
> | head |
> | vtable | itable
> | ivars | +---------+
> -->| itable +-->| offset |
> | ivars | | method1 |
> +--------+ | method2 |
> | method3 |
> | method4 |
> | ... |
> +---------+
> {noformat}
> Converting an object to an interface reference is done by returning a pointer
> to the itable struct member. Converting back to the object is done by
> subtracting the offset in the itable. Method invocation from an interface
> reference is done by looking up the method pointer and calling it with the
> original object.
> In host languages, an interface is represented by a class with the
> interface's methods. Objects of this class contain the interface reference
> (address of the itable instance variable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
