On 03/12/2014 03:47, Marvin Humphrey wrote:
For abstract classes like Query or Analyzer, making them Go interfaces works
fine. However, there are unresolved difficulties for concrete classes which
we expect people to subclass.
Don't we run into exactly the same problem as with IndexManager when writing a
custom Query or Analyzer in Go? Query isn't even marked as abstract [1] and
both classes define some non-abstract methods. From my understanding, a
Clownfish class could only be "subclassed" from Go if it contains only
abstract methods and no ivars which would make it an interface.
One thing I've come to appreciate while working on the Go bindings is that the
composition model is more universal -- besides its popularity among elite
hackers, it's more compatible with more object models than inheritance. It's
made me contemplate whether composition might be a more suitable model on
which to base a project like Clownfish.
I wouldn't question the core architecture of Clownfish. Composition works so
well in Go because anonymous struct fields are promoted and their methods are
added to the structs method set when determining the interfaces it implements.
This makes composition feel like inheritance in many cases. But all of this
would be hard replicate in C.
The actual problem is the way we handle callbacks from Clownfish back to the
host language. The current implementation is based on subclassing and makes a
lot of assumptions:
* The host language has some concept of classes and inheritance.
* The host language can somehow subclass Clownfish classes.
* A constructor can call the constructor of the parent class.
* The host language has an introspection feature to list the
methods of a class.
This works for Perl, Python, and Ruby, but some of these points would make it
hard to even support a dynamically typed language like JavaScript in an
idiomatic way.
So we really should change the whole callback mechanism to be based on
interfaces. This also means to change the parts of Lucy where callbacks are
involved. But I don't see a need to throw Clownfish's internal object model
overboard.
Nick
[1] Probably only by omission. The "abstract" modifier for classes is purely
informational, AFAICS.
