Are there any OO languages without inheritance?

Question

During a code review today, a colleague of mine said something interesting:

prototype is only useful when you need inheritance - and when's inheritance ever a good idea?

I thought about this and I realised that I usually use inheritance to get around code that was badly designed in the first place. Modern OO style prefers composition over inheritance, but I don't know of any languages which have taken this to heart and actually enforce it.

Are there any general-purpose programming languages with classes, objects, methods, interfaces, and so on, which disallow class-based inheritance? (If such an idea doesn't make sense, why not?)

Answer 1

Setting aside the question of the definition of object oriented programming the question becomes one of "are there languages which use composition only and have no tools for inheritance?"

The answer to this is quite simply "yes". In go, there are no way to do inheritance as one classically thinks of it. One can embedded an object in another object and the extend that object. From Object Desoriented Language (github mirror):

type Person struct {
        Name string
}

func (p *Person) Intro() string {
        return p.Name
}

type Woman struct {
        Person
}

func (w *Woman) Intro() string {
        return "Mrs. " + w.Person.Intro()
}

You've got a person struct that has a Name which is a String. It has a public function called Intro which returns the name. The Woman struct also has a function for Intro which accesses the strut embedded in it. And so one can fulfill the intentions of inheritance by using composition only.

More on this can be seen at GoLang Tutorials: Inheritance and subclassing in Go - or its near likeness.

So yes, it is possible to have an OO language without inheritance, and one does exist.

Within go this is known as embedding and gives enclosing structures the ability to access the embedded fields and functions as if it had them too - but it's not a subclass. The design philosophy can be found in the Go FAQ: Why is there no type inheritance?

Answer 2

Are there any general-purpose programming languages with classes, objects, methods, interfaces, and so on, which disallow class-based inheritance?

This reads very much like a description of VBA - Visual Basic for Applications, embedded in Microsoft Office and other VBA-enabled hosts (e.g. AutoCAD, Sage 300 ERP, etc.), or even VB6. The "A" of "Basic" stands for "All-purpose" anyway, so there's the "general-purpose" part.

VB6/VBA has classes (and therefore objects), methods and interfaces - you could define an ISomething interface in a class module like this:

Option Explicit

Public Sub DoSomething()
End Sub

And then have another class that does this:

Option Explicit
Implements ISomething

Private Sub ISomething_DoSomething()
    'implementation here
End Sub

Such a class, exposing no public members, could only ever be accessed via its ISomething interface - and there could very well be dozens of different implementations of ISomething out there, so OOP VBA code is perfectly capable of polymorphism, and it's perfectly legal for a given class to implement multiple interfaces, too.

VB6/VBA does not allow class inheritance however, so you can't inherit an implementation from another type, only its interface. Now, whether this is an accident, a design flaw, a stroke of genius or a huge ugly oversight is open for debate; it's not clear whether VB6/VBA takes this to heart, but it most definitely enforces it.

If Go doesn't do class inheritance and is nonetheless an OOP language, then I don't see why VB6/VBA couldn't be considered an OOP language as well. </PreemptiveResponseToVBAHatersThatWillSayItIsNotAnOOPLanguage>

Answer 3

You can make the compiler enforce selective inheritance through the use of private / protected, and through modern use of "PImpl", or "Private Implementation" techniques.

Many APIs expose only those components which you would desire a user to inherit, and hide the rest in a separate implementation class. So you could write classes whose public interfaces are, in fact, uninheritable, only usable through object composition, and compiler-enforced. This is often good practice, when it uses the compiler to enforce the intent of the software.

A quick search for private member functions in javascript show there is a similar principle, although anybody can see your code if they can use it: http://www.crockford.com/javascript/private.html