RE: multiple inheritance
I just joined this e-mail list a few days ago when the onto-std list told us how to subscribe, but I'm already concerned about some of the arguments I'm hearing.
Chris Welty wrote:
-----------------
Multiple inheritance is TOO OFTEN used to
"bundle together" properties that a class of objects may "sometimes"
exhibit. It is because of this almost universal lack of discipline
that we should consider not having multiple inheritance.
-----------------
I agree that multiple inheritance can be misused, but I hope that's not an argument to drop it from the standard. That's almost like saying that because lots of people can't follow first-order logic, we shouldn't bother building a model that's logically correct.
Being able to partition a class into subclasses along more than one dimension is basic to every large ontology that we're trying to merge (I'm guessing). For example, we may want to partition the class Person into Male-Person and Female-Person, and also into Adult-Person and Child-Person. Then to create the class Girl we'll want to make it a subclass of both Female-Person and Child-Person. Without this ability, we'd have to drop one of these partitions (say, Adult-Person and Child-Person), and stay with a strict hierarchy where Male-Person has subclasses Man and Boy and Female-Person has subclasses Woman and Girl. But then any properties of adults have to be repeated for both Man and Woman, and any properties of children have to be repeated for both Boy and Girl.
If you repeated these kinds of duplications throughout a global ontology, it would become a nightmare and a straight-jacket. But we've all known this for years, so why are we even thinking of doing without multiple inheritance??
Frank Farance wrote:
-----------------------
The C++ standards committee discovered that multiple inheritance
was a bad idea.
-----------------------
The problem is that the object-oriented programming community is working in a different paradigm, where the classes often do not represent semantic concepts, they just represent reusable code fragments that are there for subclasses to grab and use however they like. I hope this committee is defining a semantically meaningful ontology of concepts and not being sidetracked by the problems of inheriting and combining code fragments.
Nicola Guarino wrote:
-----------------------
A possible way of modeling this situation is by admitting that the concept "castle" specializes both "building" and "bunch of bricks". [...] In this case, modeling multiple views by means of multiple IS-A links is simply *wrong*, because it leads to an inconsistent theory.
-----------------------
Whether this is wrong or not depends on the definition of the class Bunch-Of-Bricks. If it means things that are jumbles of bricks (and only bricks) in no organized structure, then a castle is not one of these. If it means things that include a number of bricks (whether organized or not) and that may include other parts besides bricks, like timbers and mortar, then a castle (or more precisely, a brick castle) is one of those. But I agree with all of Nicola's arguments in favor of using multiple inheritance correctly.
Good definitions of each class are needed, and we need to be certain that when we make one class a subclass of another, that every fact about each member of the superclass is also true about each member of the subclass. With these precautions, multiple inheritance is the only reasonable way to go. (Problems do arise when we deal with default assumptions, however, and we try to inherit those from multiple superclasses.)
John Thompson
(cube-mate of Mike Uschold)
Mathematics & Computing Technology
Boeing