Every project needs an idiot

In this issue: OO basics, a refresher; or is not and.

The very basics of object technology

In the Eiffel User Group (https://groups.google.com/g/eiffel-users), as part of a longer thread, Alejandro Garcia asked:

Using this thread to ask a question that has bothered me for some time: What are the advantages of non-conforming inheritance (reuse with no subtyping)? I've seen in several places that people complain about subtyping, but I don't understand what the problem is. I mean: Java has subtyping without reuse (interfaces); Ruby and Smalltalk have reuse without subtyping (mixins); Eiffel is the one that has reuse with subtyping (multiple inheritance).

Non-conforming inheritance gives us reuse without subtyping, which seems similar to mixins, but I don't see the benefit. Sometimes I have wished for the opposite — extracting the interface of a class without any reuse (like interfaces) — but never for something like mixins. So what are the benefits? Is it purely to avoid the "is-a" relationship when you only want the code, or is there a deeper architectural advantage I am missing?

I answered as follows.

...............................................................................

The core idea of object-oriented programming, the brilliant intuition of Nygaard and Dahl (although they did not explain it in so many words), is the merging of two programming concepts: module and type. A module is a structural (syntactic) unit of decomposition, affecting the static view (program text). A type is a semantic unit, affecting the dynamic view (program execution): the description of a set of possible values. It is initially quite counter-intuitive to treat such seemingly disconnected notions as one and the same, which is why it took two decades between the start of modern programming and the design of OO technology. The result of the merge is the class, the distinctive concept of OO programming (and OO design, database, requirements etc.).

The way the counter-intuitive merge works is that the services offered by the class, viewed as a module, are precisely the operations on instances of the class, viewed as a type. It takes a while to drill this idea into one’s mind but once you have operationalized it you understand object technology.

Strangely, as far as I know no one else explains OO this way. I do, starting even before my OOSC book. Just as strangely, many people (outside of this group) who claim to have read the book also do not understand the idea, even though that is really all that the book says. Maybe that is my fault for taking 1270 pages to explain it. My experience is that people usually stop around page 7.

The beauty of the merge extends to inheritance. You look at the class as a module, and you can extend it; in this sense inheritance subsumes the idea of module reuse, as given for example by “include” or “package use” mechanisms in C, Ada, Java etc. You look at the class as a type, and you can specialize it; in this sense inheritance subsumes the idea of subtype, as you would find it in a functional language.  The versatility of the inheritance mechanism, following from the versatility of the class mechanism, comes from the type/module duality. Kind of like wave/particle. It also explains the apparent paradox: inheritance is both extension (we add features to the module) and specialization (we restrict the set of type instances).

There is no reason to restrict this mechanism, for example through the horrendous “interface” facilities of languages such as Java and C#, which put an unacceptable expressive restriction on the programmer, or through the restriction to single inheritance. (For more details, see my 2024 “Right and Wrong: Ten Choices in Language Design”, part of the collective book “The French School of Programming”, preprint at https://arxiv.org/pdf/2211.16597. For the full book, see the Springer page.)

I can think of no obvious case in which — out of the two views — you need only type specialization, but it can happen that you need only module reuse. For example you might want to inherit from a facility class which encapsulates math constants. (There are other ways to reuse, such as non-object call in Eiffel, but often inheritance is simpler.) In such cases subtyping would not really  be wrong but it causes irrelevant technical problems (the need to disambiguate features in repeated inheritance) and you can avoid them by declaring the inheritance link to be non-conforming. An added level of flexibility, extending the OO programmer’s basic toolset.

Or is not and

On the lighter side: Boolean logic is not commonly taught and I often see examples of basic De-Morgan-violation confusions (“entry forbidden to unauthorized or unaccompanied persons”). But the one below, in a California furniture shop, does not even involve negation:

You have choice: you can touch, as long as you are gentle; and if you refrain from touching, you do not have to be gentle. What a generous policy.

Want to read earlier newsletters (back to October 2025)? They are archived here.

Cover photo: Lippizan horses, Slovenia.