Re: Clean Object Class Design -- Circle/Ellipse

From: Tak To <takto_at_alum.mit.edu.->
Date: Fri, 10 Aug 2001 12:28:46 -0400
Message-ID: <3B740BBE.EFC0DFCD_at_alum.mit.edu.->

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 - 18:28:46 CEST