Re: Date's First Great Blunder

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c5ia56$t04$1_at_news.netins.net...
> C. J. Date has written about what he calls "The First Great Blunder"
related
> to this question: What concept is it in the relational world that is the
> counterpart to the concept of object class in the object world?
>
> He suggests that there are two answers given: domain = object class or
> relvar = object class. He then says that the first equation is obviously
> right and the second wrong. Classes are types and domains are types, but
> relvars are variables and, therefore, not types, so QED.
>
> The idea, it seems, is to rid Java programmers of the notion of using
> classes to define "relations" or records. I'm guessing I'm not the only
one
> who doesn't buy Mr. Date's argument.
>
> I'll toss out one of the way-too-many-thoughts buzzing in my head on this
> topic. How about this equation:
>
> Class = Metadata
>
> A class is a spec/template -- not a variable nor an object. There can be
> metadata for a type and metadata for a relation/record and classes
> corresponding to either.
>
> Do many folks agree with Date on this point or is this one of his
> lone-ranger attempts to push against the OO folks? --dawn

I do agree with him, although his use of the term "counterpart" isn't exactly right. Part of his agenda is pointing out the overloading in the use of some OO terms, and the vagueness in others (not necessarily a disjoint set).

Using terms like "spec", "metadata", and "template" requires some definition as well.

What is metadata for a type, other than the type itself? Relations have types, as do tuples (simply and not very precisely, the relation has a heading which has the same type as its allowable tuples).

In any event, the crux of his argument is that types are to relations what nouns are to sentences, separating the values we can talk about from what we're saying about them. OO allows excessive and unnecessary leniency, in that an object is a variable, or rather a record with both variables and functions, and the values of its variables can be other variables, etc. etc. This is confused in ways that force the use of patterns and conventions such as immutability / "value classes", enumerations, factories and factory methods, and many other techniques enforcable not via automation, but purely via human obedience and review. Aliasing is a major problem in OO applications, and has spawned research which, interestingly enough, has many different solutions. This suggests, although the field is young, intractability.

So if you suggest that classes can correspond both to types and to relations/records, in what way do we prevent the varying needs of each from overlapping in destructive ways? In the OO community there are patterns galore to govern how you build your classes, some corresponding more to types and some more to relations/records (and then more to helpers, utilities, managers, DAOs, ad nauseum). Unfortunately, there's also the opportunity to spawn bastard hybrids - more invitation than opportunity, really. In what way does the concept of class then help, if we have to take measures to coral our classes back into the appropriate camp? And if we work best with classes classified as either collection variable or as type, then why fuse the two together?

So far we've spoken only of types, both "basic" (domains) and tuple types (records). A relation (specifically a relvar) has not only a type but a value. Does a class correspond to the "type of the relvar" (e.g. the "metadata"), or to its current value, the tuples currently stored in it?

I'll close with one of my favorite quotes. Oh, I can't pick just one, so here are a bunch of related ones from Dijkstra:

"... all unmastered complexity is of our own making; there is no one else to blame and so we had better learn how not to introduce the complexity in the first place."

"The sore truth is that complexity sells better. (It is not only the computer industry that has discovered that.) And it is even more diabolical in that we even use the complexity of our own constructs to impress ourselves."

"It is a genuine sacrifice to part from one's ingenuities, no matter how contorted. Also, many a programmer derives a major part of his professional excitement from not quite understanding what he is doing, from the daring risks he takes and from the struggle to find the bugs he should not have introduced in the first place."

"... pay the greatest possible care to the choice of concepts in terms of which we have built up our theories: we know we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of our own making."

"The moral is clear: prevention is better than cure, in particular if the illness is unmastered complexity, for which no cure exists."

• erk

P.S. I'll add, to avoid the stamp of anti-object bigot, that I've been programming nearly exclusively in Java/J2EE for the past 4 years, so while I will never claim to be an expert, I am at least well-versed in the practice and the literature. Received on Wed Apr 14 2004 - 15:21:41 CEST