From: WF

To: Editor

 

C. J. Date's recent advertisement for his UCLA course on "type inheritance" makes me desire to contact him.

 

There is a simple, very well understood, clear, and entirely applicable concept of "type", more than 50 years old, that you seem to disregard, in the usage "type inheritance".  This is part of Tarski's systematization of model theory and his theory of definition.

 

Relationships between types do not need the concept of inheritance.  They have the relations’ subtype and identity.  These relationships may be stipulated as invariants of a system (axioms of the specification, in the cases where the types are primitive terms of the specification), or demonstrated from the definitions of the two types, in the cases where those types are defined terms, and not primitives.  Where Types A and B are mentioned in a single specification, then Type A is a subtype of type B if an only if in every system that satisfies the specification, every instance of type A is also an instance of Type B.  And A and B are identical iff they are subtypes of each other.

 

For example, we may demonstrate that the type, PCpointOnEarth, which we have defined as a point on earth specified by polar coordinates, is identical with the type CCpointOnEarth, which we have defined as a point on earth specified by Cartesian coordinates. A type is a mathematical abstraction of a term in a specification that can be represented by the equivalence class of all the interpretations of the type in every system, which satisfies that specification.

 

The ability to discover such identities is of course very important for the federation of different systems in which types are defined independently. Inheritance, on the other hand, is a reuse relationship between pieces of language, not between mathematical abstractions. For example, while a definition of equiangular triangle might reuse a definition of isosceles triangle, it does not reuse a definition of "triangle with two equal sides". A few of us, in some circles, (the Reference Model of Open Distributed Processing and most recently even in the Object Management Group) have spent a decade trying to clear up the silly confusion between inheritance and subtyping that has led to so-called "paradoxes". It is sometimes desirable to reuse a piece of language in contexts in which subtyping is not preserved by that reuse.

 

More generally, it troubles me that you say, "the research community has not been of any help". It seems to me that the CS research community is fixated on 19th century mathematics (naive set theory), and once they come to use some 20th century mathematics, (say model theory), problems that plagued naive set theory, such as a clear distinction between extension and intension, will go away.

 

My interest in writing to you is based on my desire to achieve communality between mathematical concepts and the diverse endeavors by computer scientists such as yourself to formulate the same concepts, when the differences seem to be gratuitous, resulting is the tower of Babel that we find ourselves in computer science.

 

 

Chris Date Responds: Let me begin my response by saying I'm very much in sympathy with your final paragraph, and everything that follows should be interpreted in that light.

 

That said, I have to say that, for me, what you have to say falls into two categories:

 

1.   Parts that I don't understand (probably because I don't have the necessary background);

2.   Parts that I do understand and either agree or disagree with.  Where I agree, I find no implications for our inheritance model. Where I disagree, I also (more obviously) find no implications for our inheritance model, either.

 

Note: "Our" here refers to Hugh Darwen and myself.

 

One general point is this:  I couldn't tell from your note whether you had actually studied our inheritance model or whether you were just trying to make a more general point.  If you have studied our model, then I'd be anxious to see your answers to the following questions:

 

·   Do you have any specific objections to that model? 

·   If so, what are they?

 

I should tell you that we've presented our model to quite a number of people, both in live presentations and in written form, and nobody has ever shown us that it's entirely wrongheaded (there have, of course, been valid criticisms of specific points, which we've acted on).  And our audiences have from time to time included people quite knowledgeable in the field.  I should also admit that I had a very frustrating exchange with Bjarne Stroustrup over the differences between his (C++) model and ours.  Although he never agreed that we were on to anything useful, at the same time he didn't show that there was actually anything wrong with our approach.

 

Another general point (this one contributed by Hugh Darwen):  We don't really use the term inheritance in any formal way in our approach; we simply inherited it (sorry) from the object community and found it useful in informal discourse, that's all.  (Also, "Type Inheritance" makes for a snappy and not too wildly inaccurate title.)  A value of type T "inherits" all of the proper supertypes of T.  More important, and perhaps more precisely, it "inherits" all of the operators defined for values of those proper supertypes.  It's not that we're greatly enamored with the term inheritance for the purpose at hand, but it's a lot less objectionable than much of the terminology that's put about in our business.  In any case, we could agree not to use the term at all and redefine our model accordingly, and the result would still be logically equivalent to what we already have.

 

Let me now make some more specific responses to your note.

 

Ø       I'm not familiar with Tarski's work.  This might be a shameful admission, but you can't be familiar with everything.  I'll try to find an account that I can understand.  Naturally I'll have to reserve judgment as to whether that work is, as you claim, "simple, very well understood, clear, and entirely applicable" to the problem we're trying to solve.  However, I have to say that some of the points you make later in your note make me a little suspicious in this regard (perhaps I should say skeptical), though of course I'm prepared to keep an open mind on the question.

 

Ø       You say:  "Relationships between types do not need the concept of inheritance.  They have the relations subtype and identity."  To the extent I understand these two sentences, they seem to contradict one another.  (In the second sentence, I take "They" to refer to types and "relations" to mean what in the first sentence you call "relationships.")  To us, the concepts of subtype and inheritance are intimately related; in fact, type B inherits "properties" from type A if and only if type B is a subtype of type A.

 

Note: I don't want to get sidetracked here into a detailed discussion of what we mean by "properties" in this context.

 

Later in this paragraph, you use the term instances.  Now, you might have a very precise definition of that term in your mind, but it's our experience that most people who use that term don't.  We don't use it ourselves, preferring the more specific terms value (when it's values we're talking about) and variable (when it's variables we're talking about).  To us, much of what's wrong with other, more widely documented approaches to inheritance is rooted in a failure to make a clear distinction between these two concepts (i.e., values and variables).

 

Having said all of that, I now add that your remark to the effect that (paraphrasing) "B is a subtype of A iff every B value is also an A value" sounds very close if not identical to our own notion of what it means for B to be a subtype of A.

 

Ø       Your examples of PCpointOnEarth and CCpointOnEarth seem to me to confuse types and representations.  In our model, we would say there's just one type here, PointOnEarth, with two possible representations ("possreps"), polar coordinates and Cartesian coordinates.  Our model takes it as a given that there's an important logical difference between these two concepts (i.e., type and representation).

 

I think there has to be a way of saying what you seem to be trying to say in the second sentence of your third paragraph that's both clearer and more precise.

 

Ø       "Inheritance ... is a reuse relationship between pieces of language."  Well, OK:  You're entitled to your opinion.  One thing we've learned in our work on this subject is that everyone has his or her own definition of the term inheritance (and, frankly, I'm getting a little tired of being told that ours is categorically wrong, inheritance doesn't mean that, it means this, etc., etc.).  In our work we explicitly recognize the fact that the term has many interpretations, and we discuss several of them.  We then go on to define certain patterns of behavior, and we say "this is what we mean by inheritance."  But what's in a name?

 

Your example regarding triangles is unclear to me.  But we could certainly define Equiangular Triangle to be a (proper) subtype of Isosceles Triangle, which in turn we could certainly define to be a proper subtype of Triangle.  And we could regard subtype definitions as "reusing" supertype definitions in such a situation, though we don't usually talk that way.

 

Note: Hugh Darwen adds:  In fact, we find your choice of example interesting, in that we agree with it but much of the community probably wouldn't!  See the article Is a Circle an Ellipse?.

 

I was interested (not positively) by your mention of the Object Management Group.  Most previous work on inheritance (in the computer science world, at least) seems to have been done in the context of "objects," and--object being, like instance, a term that doesn't seem to have a universally agreed definition (and a term that we find no need for in our own work)--we think that's what's wrong with it!  In fact, we contend that "objects" as usually implemented in the object world and a good model of inheritance are fundamentally incompatible.

 

You mention "so-called paradoxes."  We are aware that most approaches to inheritance described in the literature lead to "nonsquare squares," "noncircular circles," and similar nonsense.  If these are what you mean by "paradoxes," then I'm pleased to be able to tell you that our own inheritance model is 100% free of such things.

 

Ø       You claim I say "the research community has not been of any help."  I'm not sure I ever said exactly that--I can't find these words in the seminar description as I originally wrote it--but I admit the sentiment is close, somewhat, to what I believe.  However, the research community I have in mind here is, of course, the languages and database research community. You might well be right that the problems we're trying to solve have already been solved in the mathematics or logic community.  In which case I'd be interested in discovering where their solution differs from ours...

 

I don't think we suffer from any confusion over the distinction between extension and intension. 

Ø       See my opening remarks.

 

 

Posted 08/22/03

 

 

 

[ABOUT] [QUOTES] [LINKS]