Re: relations aren't types?
Date: Sun, 21 Dec 2003 21:01:04 GMT
Message-ID: <kSnFb.172699$_M.781016_at_attbi_s54>
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:bs38nn$oqm$1_at_news.netins.net...
>
> I have read and re-read Date & Darwin's rationale for using classes to
> define types that are domains of attributes in a relation. I completely
> agree that is an appropriate use of a class. But the reasons for not using
> a class to define a type that is either a relation (or, my preference -- a
> function) or an element of the same are not at all satisfying. That is,
> I've read the rationale and I don't buy it.
I have to agree. I don't see any logical difference between a row in a relation and an object. (Alternatively, between a relation heading type and a class.) I too have read and reread the appendix in TTM on "the first great blunder" but I don't see anything blunderous about it.
Well, maybe one thing. OOPLs are heavily into use of pointers or references, and these don't work well with relational data management. But that's not a showstopper in my book. It seems eminently possible to design a data-management OO (or "OO-like") PL that didn't have pointers or references, but leaned heavily on relations instead.
Maybe one would have to call them ADTs and not classes at that point. I can't say I care too much. The important part of OO is polymorphism, and that works just fine with ADTs.
Hmmm. Dawn and I are agreeing on something. :-)
Marshall Received on Sun Dec 21 2003 - 22:01:04 CET