Maybe it is a bit late to ask but do we really need inheritance?

Advantages:

• widely used, well known OO concept,
• allows code sharing with little boilerplate,
• full support in JVM/CLR

Disadvantages:

• doesn't very well play with encapsulation (you mostly have to know all the details of a superclass to make a sane subclass)
• readability suffers (you have to go through all ancestors to find out what the code is really doing - sometimes this is pretty tricky)
• avoiding problematic diamond inheritance crippled reusability
• construction and contracts for object hierarchies are complex problems (mostly solved wrong in real code)

What do we model using inheritance in Fan? Is there another reasonable way to do that? Could we dump the inheritance in language (possibly by replacing the concept by other constructs like Mixins) or do we need to support it because we are on top of JVM/CLR?

Most of toughest discussions here tackled inheritance: constructors/with-blocks, type variance, now the concept of equality... What does it buy for us? Couldn't we keep it under the hood instead of exposing it?

Inheritance sucks but Fan is a Java/C# successor, not a successor-of-the-successor-to-Java/C#, and as such should largely follow the accepted conventions of these languages.

That said, I wouldn't mind some easy way to delegate:

class A : IObserver, I2 {
    new make() {
        this.I1 => new DefaultObserver
        this.I2 => new XXX
    }
}

Java is a successor of C++ and it did change its inheritance model (interfaces instead of multiple inheritance) and encapsulation (new modifiers instead of friend classes). I think a few people would miss it if they had better ways how to explain the same (using simplified delegation (C# does this in a way), composition and mixins.

EDIT: just a reference to a former discussion (mostly) about this topic.

Since Fan is based on the JVM and .NET, I think class based inheritance plays a very important role. It is the fundamental model of both VMs and will be critical to smooth Java/.NET library interop.

I also happen to think inheritance is a very useful technique. Fan mixins solve my biggest gripe with the interfaces - since they allow us to avoid the boiler-plate code of manually routing interface methods to common implementations.

That said, I don't think class based inheritance is everything to be said on the matter. I like to use composition in my designs. And I'm hugely influenced by Self and prototyped based inheritance (love the model, not the performance). So I hope over time we figure out how Fan can cleanly use other modeling techniques.

it will be critical to smooth Java/.NET library interop.

I absolutely agree that Fan has to know about it and handle it well internally. But do we have to expose it directly as a language feature? Maybe it would make our life actually easier if we didn't...

I also happen to think inheritance is a very useful technique

I find it very useful in Java, much less in Fan. Could you point out some real-life Fan-style examples? If not for this discussion they might be useful to get contract definitions or supplementary features right.

Similarily, I find method overloading also a useful technique, on the other hand I agree that it adds a lots of unnecessary complexity. Leveraging inheritance in Fan adds even more.

So I hope over time we figure out how Fan can cleanly use other modeling techniques.

I hope so whatever the result of the inheritance issue is ;)

I use inheritance successfully all over the place:

• IO Streams
• Buf specializations
• Tests
• Compiler AST and step classes
• Widget class hiearchy
• fandoc::DocNode
• email::EmailPart
• fwt Command
• flux Views
• flux Sidebars

I think it is nice to talk about alternatives to inheritance, but close to twenty years of main stream OO programming has proven that inheritance is a very solid technique.

You will note that Fan defaults methods to non-virtual and I am extremely careful about making methods virtual. I believe that if you follow this practice that inheritance tends to work out quite well.

I found an old but very interesting article discussing subtyping and subclassing differences -- nice and simple examples presented.

Regarding the text I think Brian's decision about equal and compare with respect to inheritance is the best way out.