| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: Clean Object Class Design -- Circle/Ellipse
Tak To <takto_at_alum.mit.edu.-> wrote in message news:<3B72D2A0.DED3971C_at_alum.mit.edu.->...
TT> I have not been following this thread closely nor have I study TT> Date's theory in detail. However, it seems to me that Date's TT> notion of "type" is defined solely by a set of membership criteria TT> and hence a subtype-supertype relationship is based on the pre- TT> sevation of membership when going from subtype to supertype (i.e., TT> that the proposition "is_member_of_subT => is_member_of_supT" TT> is true).
peter_douglass wrote:
PD> I'm on vacation at the moment and don't have my Date books PD> with me, so what I write may not reflect Date's views, but PD> here goes. Typically, all values of a given type must share PD> some common properties. Types would be next to useless without PD> such. All common properties which are shared by every value PD> of a type must be shared by every value of the subtype. This PD> includes operations.
But some of properties of an operation pertain to the set of values itself rather than individual values (e.g., closure rules). Hence the difference.
Incidentally, in which of Date's books does he talk about this?
TT> I think Date says it quite clearly that operations are not TT> automatically inherited.
PD> Not per-se, but there must be a way to implicitly cast from a PD> representation of a subtype to a representation of a type. If PD> you put a circle in a column whose domain is ellipses, then PD> the you may ask the circle for it's foci, eccentricity, etc, PD> just as you could if you had put in an ellipse representation PD> that happened to be a representation of a circular ellipse.
Well, I was not referring to representation issues. I was referring to preserving the meaning (and validity) of operations independently of representation.
[...]
PD> One might also argue that as a practical matter, one PD> _needs_ mutable ellipses and mutable circles. [...]
TT> Note that this difference is independent of the issue of
TT> mutability of objects. Consider the question of whether { 0, 1 }
TT> is subtype of Integer . Clearly, ordinary addition is not well
TT> defined on { 0, 1 } but both 0 and 1 are members of Integer.
TT> (A similiar problem has been proposed by Mr Martijn Meijering
TT> in this thread -- whether Integer is a subfield of Rational.)
PD> Clearly ordinary addition is not defined on {0, 1} if you
PD> mean that ordinary addition is closed over this set, i.e.
PD> that the result lies in this set. However, ordinary
PD> addition is clearly well defined on {0, 1}. It just so
PD> happens that the results are often outside the
PD> set. Let's call {0, 1} "Bit". You can put Bit values in
PD> any database column that expects Integers (or Rationals,
PD> or Reals) and everything will work as expected.
Correct, this would satisfy Date's notion of subtype but not that of LSP, which is precisely my point.
Tak.
-----------------------------------------------------------+----------
Tak To takto_at_alum.mit.edu.-
--------------------------------------------------------------------^^
[taode takto ~{LU5B~}] NB: trim the .- to get my real email addr
Received on Fri Aug 10 2001 - 11:28:46 CDT
 |
 |