From: CWU
Date
1. First, and amusing quip about how, in a discussion of
projection, how it might necessitate the elimination of duplicates and why this
is necessary, a third party piped up "Hey, I really don't see what the big
deal is about this 'relational projection', SQL can do it just like this!
...". Oy!
2. Second, a quick note regarding the 8th edition of AN INTRODUCTION TO DATABASE
SYSTEMS:
Although valid, the criticisms of poor implementations of OO features as
discrediting OO is akin to criticisms of poor relational implementations
discrediting relational theory. As quite truly stated, there is no formal
OO model; however many of the complaints brought forth can be (and have
been) answered in appropriate ways; instance variable accesses having the
same syntax as (and therefore replaceable with) method invocations (Eiffel,
C#), no 'privileged' argument in Lisp-style multi-methods, etc. Furthermore,
these are widely considered to be Good Things, except that they're complicated
to understand, and therefore avoided for the sake 'lesser programmers' (when
will people learn that the alternative of arbitrary distinctions in a language,
especially for 'lesser programmers', is not a good thing?).
3. Switching to a different (and more interesting) topic;
People keep wanting to use tuples/rows as objects, despite the obvious
correlation between types (formally domains?) and classes. Even beyond the
whole 'types and classes' statement in itself, one considers the most
fundamental property of OO, the ability to create new types with its own
operations, i.e., to create something on equal footing with the numbers,
strings, etc., that most languages provide.
4. Myself, I even want this, the allure being the possibility of joining tables
and having the proper 'class' materialize to handle it. I feel this is
what many people actually want, as can be seen by the fact that they often
write out long-hand the classes to handle the specific cases they use.
And it almost works (especially in dynamically typed languages).
5. Perhaps what is needed is a split of OO, into the creation of new types with
associated operators (although I personally dislike the_syntaxOf(yourTypeModel),
it would be completely appropriate for what I have in mind), and the definition
of a form of multi-method. Namely, that such a method accepts a single
tuple (row) or relation (table), and returns a single tuple or relation.
6. An interesting effect of this would be making such operations set-centric,
in that any operation can be called in the same way for any number of
tuples. The full relational algebra could be brought to bear against
repetitive-but-varying method calls: i.e., "forEachTupleIn(relation,
doThis)"; if 'doThis' should vary depending on a given tuple,
there's no choice but to repeat the call with the appropriate restrictions on
'relation' for each possible value of 'doThis'. The alternative would allow
us to perform this as, for instance, a join between 'relation' and the set of
tuples representing the possible values of 'doThis' with the determining
attributes of 'relation'. In effect, elimination of what would otherwise
be a duplication of language features.
7. I am already working on an implementation of this (among other things), and
am very interested to know with you feel there is any merit in this approach.
Chris Date Responds:
1. I like this story.
2. Regarding "akin to criticisms of poor relational implementations
discrediting relational theory", not really. [Ed.
Note: If you read carefully our criticism, it is fundamentally
about the so-called "object model" (which one, as there are many),
not about implementations].
4. Don't understand the "joining tables...class materialize" bit.
6. Don't understand this stuff at all.
Posted 11/12/04
