Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Object Class and Data Type

Re: Object Class and Data Type

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Wed, 31 Mar 2004 14:02:05 GMT
Message-ID: <xbAac.46098$Ab6.3145@newssvr16.news.prodigy.com>


"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0403301522.3f18ba3_at_posting.google.com...
> > A class hierarchy is intended to relate entities based on common
behavior;
>
> Actually a class is simply a user's way of organizing things based on
> some general characteristic which usually implies those thing have
> common behavior, just as values of a domain will.

A collection of my thoughts, in random order:

A class hierarchy typically munges together several distinct concepts. One is usually type (aka ADT), and one is usually code reuse. The proper characterization of subtyping is that of subset; if SUB is a subclass of SUPER, then all instances of class SUB are instances of class SUPER, but not (necessarily) vice versa.

Regarding the "contracts" of those classes, a subclass cannot require more than its superclass, though it can require less; and a subclass can promise more than its superclass, but cannot deliver less. This is the reason why (for example) in Java a subclass can opt NOT to throw an Exception declared in the overridden superclass method, and can return an instance of a subclass of that method's return type. Unfortunately for Java, it can't relax the parameter types very easily.

See Date's specialization by constraint, esp. in The Third Manifesto. See also any of the writings of Luca Cardelli, esp. those regarding covariance and contravariance.

> [snip]
> The base "type" of "data type" (ie int, char, str) is thing. Int is a
> thing. char is a thing. str is a thing.

Agreed - Java's mongrel C-derived split type system is an atrocity. Hopefully .NET doesn't have the same thing.

> It is difficult to see and
> implement this in RDM because it's lowest fundamental unit of
> abstraction (aka relation) doen't go low enough.

Huh? Types are completely orthogonal to relations, but Date and company go into great detail about them nonetheless, both in Intro to DB Systems and in The Third Manifesto. The implementation problems are due to pathetic support for types in SQL (maybe SQL:2003 is better). Since relation headings are composed of attributes, each of which has a type, it makes no sense to say that "it's lowest fundamental unit of abstraction" is the relation.

Received on Wed Mar 31 2004 - 08:02:05 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US