On Sun, Jun 7, 2015 at 12:22 PM, Nick Wellnhofer <[email protected]> wrote:
> On 07/06/2015 17:23, Marvin Humphrey wrote:
>> For Go, we haven't quite
>> nailed it yet because the subtyping model, once it supports
>> overriding, will produce non-idiomatic behavior that Go programmers
>> will find surprising.
>
> What do you mean exactly?
Go doesn't support classical inheritance -- including method overriding:
http://play.golang.org/p/TP8qGZr7UM
---- Foo:
From the outside, I look like a Foo.
In my heart, I'm a true-blue Foo.
---- Imposter:
From the outside, I look like a Foo.
In my heart, I'm a true-blue Foo.
Under Clownfish, you get classical inheritance from Go -- which from the
perspective of a Go programmer is surprising, non-idiomatic behavior:
http://play.golang.org/p/IFhhWcxwmd
---- Foo:
From the outside, I look like a Foo.
In my heart, I'm a true-blue Foo.
---- Imposter:
From the outside, I look like a Foo.
Bwa-ha-ha! I'm actually an Imposter.
We *need* to support method overriding from Go in order to unlock certain
features of Lucy. For instance, there are methods on IndexManager which you
need to be able to override in order to tune locking and merging behavior.
In my opinion, by choosing single inheritance for Clownfish, we didn't quite
get the lowest common denominator polymorphism model right once you include Go
in the mix. (And maybe Rust?)
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.)
>> * subtyping behavior
>
> If you mean to subtype Clownfish classes from the host language, I think
> this is a feature that we should consider to drop.
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.
Marvin Humphrey
