Re: The Practical Benefits of the Relational Model

Nathan,

I'm surprised that you let Mr. Date reply when the message was in reply to your slighting remarks with regards to the "OO pooh", to which your product based on Date & Darwen proposal is supposed to find all the cures.

I took notice of Mr. Date's reply, and I'll choose to reply to him in private to the more important issues, because I see no fun in corresponding with Mr. Date through intermediaries. I'll leave to his lattitude to post whatever interesting things - if any- may come out of it.

But since you are the one who claimed in this thread that OO has pretty much all the bad qualities and the relational model (or to say more acurately: the proposal of Date & Darwen for "future directions of data and database management systems") comes and cure them all, including the "type inheritance" , I'll ask you if you did your homework and read the references I gave you.

Having read those references how do you see the initial statements that you've made?
Are you aware now of the difference between subtyping and inheritance, and what is the practical benefit of separating subtyping from inheritance?

I ask you these questions, because I don't want top engage with you in a long discussion where I have to restate all the things that you ought to have read, should you have tried to properly *learn* about the domain of which you are making such bold claims.

Costin Cozianu

P.S. I added below a few clarification with regards to some of Mr. Date's minor issues, especially with regards to terminology

• Original Message ----- From: "Nathan Allan" <nathan_at_alphora.com> Newsgroups: comp.databases.theory Sent: Tuesday, September 24, 2002 6:19 PM Subject: Re: The Practical Benefits of the Relational Model

> Here is a reply from C. J. Date. Any typos are probably mine, not Mr.
> Date's.
> -Nate
> ----------------------------
> Nathan Allan forwarded to me a message he had received from you, dated
> September 4th, in which you made some slighting references to work by
> Hugh Darwen and myself on type inheritance. I would like to respond
> to that message. Text in quotes is taken verbatim from you original.
>
> "This is simply not true. There is no well defined and formal model
> of 'type
> inheritance' as part of the relational model. As you noted, relational
> model is kind of orthogonal to types."
>
> Well, it isn't clear, is it, what your opening "This" refers to.
> Nathan EXPLICITLY said that the relational model and types are
> orthogonal (as you EXPLICITLY admit), and Darwen and I have EXPLICITLY
> stated in our Third Manifesto book and elsewhere that "types are
> orthogonal to tables" (see, e.g., the Third Manifesto book, 2nd
> edition, page 21); so you can't be suggesting that Nathan or we are
> claiming anything to the contrary; so that's not what you are stating
> "is simply not true." I have to conclude that what you think "is
> simply not true" is that there is a "well defined and formal model of
> type inheritance as part of the relational model." But since you
> agree that we agree with this statement, what exactly is it that you
> think "is simply not true"?
>
> "Of course you're probably referring to Date&Darwen's proposal in
> the Third
> Manifesto, and is probably a value judgement to say whether that is
> formal and well defined, but within a safe margin we can say it
> doesn't meet the criteria."
>
> I suppose that, in the final analysis, just about everything is a
> value judgment, and everyone's entitled to his or her own opinions
> (and values, come to that, within limits). In the field of science,
> however, it is generally accepted that we should strive for
> commonality--even universality--of opinion as much as possible. Thus,
> to say, in effect, that in your personal opinion our proposal "doesn't
> meet the criteria," without giving any indication as to what those
> criteria might be, is not commentary worthy of a professional or a
> scientist. Especially when you qualify that opinion with the phrase
> "within a safe margin"! <bold>At the very least you should point to
> specific parts of our proposal that you think are inadequate, and you
> should then explain specifically why you hold such an opinion.</bold>
> Then we and others can judge your opinions on their merits. As they
> stand, your comments are unsubstantiated and unsupported, and to this
> reader, at least, they appear just a trifle arrogant. (And please
> note that they would appear that way to me even if I were not one of
> the injured parties.)
>
> "But first of all you're using bad terminology, it's not 'type
> inheritance', it is _subtyping_. Subtyping and inheritance are
> look-alikes but they should be treated distinctly. Type inheritance
> is the term Date&Darwen came up with after collecting almost all the
> bad references from the OO literature ... and almost no good one ...
> ."
>
> Part of the point here--as explicitly stated by Darwen and myself in
> our Third Manifesto book and elsewhere--is precisely that there is no
> consensus on the meanings of terms such as subtyping and type
> inheritance.

There is no such "lack of consensus". Type theory is a well established discipline rooted in mathematics and logic which became especially important and evolved substantially when developped in the context of computer science. So it is not an OO only issue, it's also an issue that is important to functional programming, logic programming, constructive mathematics and a few other areas. Therefore I can safely say that there's a _large_ consensus, in that none of the relevant books that I've been able to look at talks about such thing as *type inheritance*. They all discuss _subtyping_, or to say more exactly: the subtyping relation is the closest concept to what is described in the "Third Manifesto" under the name of "type inheritance".

"Type inheritance" as such does apear in some OO books here and there, though I think the prevalent term is "class inheritance". In most OO model a class automatically defines a type, but the reverse is not generally true. Other papers have specifically treated the distinction between inheritance and subtyping, what are the important practical and theoretical consideration for this separation.

> PRECISELY because of this lack of consensus, we offer
> our proposal as a contender for filling the gap (this fact too is
> stated in the Third Manifesto book). Thus, for you to state that our
> proposal is "not 'type inheritance,' it is subtyping" is to beg the
> question!

Date's premise is wrong. The consensus depends on whom one quotes, if I am to quote some "references" on database literature, I could easily reach the conclusion that there's no consensus on whether relational database should be based on "bags" rather than sets. It is the duty of an author to discern the science from junk, and to relate and reference the relevant work in the domains he's writing about.

Here are some references, in addition to what I posted in previously:   Abadi & Cardeli: "A Theory of Objects"   Schewe & Thalheim : Readings In Fundamentals Of Object Oriented Databases   Bruce: Foundations of Object Oriented Languages (Types and Semantics)

And maybe the most concise explanation of the basic issues can be found in:   Luca Cardelli: Type Systems (article available on the web), part of "Handbook of Computer Science and Engineering"

> That is, your <i>opinion</i> relies on an <i>assumption</i>
> that the terms "type inheritance" and subtyping" have universally
> agreed meanings--which they manifestly do not.

The term "type inheritance" is used extremely rarely in /some/ OO literature (which IMO is exactly that part of literature that has no scientific value, and from a software engineering point of view is responsible for the retardation of Object Techonology as we see it in practice), and not once in 5 seminal books related to Type Theory. Adding to that the fact that the term is prone to propagate the confusion between _subtyping_ and _inheritance_, it is safe to say that type inheritance is at best a misnomer, and has no useful place in the vocabulary of either software engineering and computer science. I find it unfortunate that probably due to a less than careful study it was chosen in The Third Manifesto.

Therefore "type inheritance" has no universally agreed meaning because it is generally agreed that it is irrelvant as a term.

As to subtyping, there's a very large consensus : A <: B (A is subtype of B) iff the judgement x:A "x has (is of ) type A" implies x:B. Although in slightly different terms corresponding to different type systems, I found no evidence that anyone proposed anything else for the subtyping relation.

> Frankly, your position
> here looks like an arrogant one again, at least to me.
>
> As for your
> assertion that "subtyping and inheritance ... should be treated
> distinctly": Well, that assertion might be valid, but it needs to be
> substantiated.

It is substantiated in a considerable body of scientific literature that I'm not going to repeat it on Usenet.

> Incidentally, I'd be interested (though not very) in learning how you
> know that "Date&Darwen came up with" the term <i>type
> inheritance</i>--regardless of whether or not we did so "after
> collecting almost all the bad references from the OO literature .. and
> almost no good one." My own recollection (and I was there, and you
> weren't) is that we didn't "come up with" the term at all. Rather, we
> were aware that the term was already being used out there in the
> community, and we wanted to see if we could make any sense of it.

That was a big mistake, because being published in a respectable book by most reputable authors it gave it some legitimacy when it is a methodological mistake on two counts:

• it confuses two aspects (subtyping and inheritance)
• it is a disregard of a large body of previous scientific work.

> Myself, I think we did--more sense, in fact, than I perceived in
> certain portions of the literature.

I as a reader was disappointed by the choice of references. And for those portions of OO literature, I frankly can't see how even Mr. Date can ever make sense of.

> "To get an idea what is needed to present a formal and well defined
> type system proposal, and all the issues a type system needs to
> address you might want to access some very good introductory book
> available on the web" [specific references omitted here].
>
> Maybe. Personally, I think it would be more helpful in the context of
> a commentary such as the one you were offering to Nathan to state some
> specific criteria and to show specifically where our proposal falls
> short with respect to those criteria.
> ----------------------------

In Luca Cardelli's "Type Systems" there are a couple of paragraphs very relevant to this discussion:

• Expected properties of type systems
• How type systems are formalized

Given that The Third Manifesto doesn't even try to meet those criteria, that it doesn't use the consacrated language, notations and concepts of type theory, that the language is called "Tutorial D" and is not intended as a fully developped (production) language, I came with a "value judgement" of my own, that The Third Manifesto contains a proposal of the _properties_ (prescriptions) that the type system of a future language D is required to have, from the perspective and the needs of data management.

I didn't assume that the Third Manifesto actually contains a *formal* type system. Even the language and style of the book led me to such a conclusion. It is in this sense that I said "it is simply not true [that relational model have a formal and well defined model of type inheritance]". And that Date&Darwen's proposal doesn't meet the criteria by a safe margin. I never took the _requirements_ for a future type system of a future language as the type system itself, so it wasn't a slighting remark (IMO). If Mr. Date felt offended by it, I frankly don't know how I can withdraw it and replace it with something else. Received on Thu Sep 26 2002 - 08:48:14 CEST