Re: Clean Object Class Design -- Circle/Ellipse

Tak To <takto_at_alum.mit.edu.-> wrote in message news:<3B72D2A0.DED3971C_at_alum.mit.edu.->...
> peter_douglass wrote:
> PD> [...]
> PD> Now you bring in the circle/ellipse issue. Date's theory
> PD> involves distinguishing variables from values. Things that are
> PD> updatable are variables. Any property that is true for each
> PD> value of a type must be true for each value of a subtype. If
> PD> you stick with values, then you will discover, I believe, that
> PD> any property that applies to every ellipse also applies to every
> PD> circle. There is no contradiction here. Date's object model
> PD> thus appears to be internally consistant.
 

> I have not been following this thread closely nor have I study
> Date's theory in detail. However, it seems to me that Date's
> notion of "type" is defined solely by a set of membership criteria
> and hence a subtype-supertype relationship is based on the pre-
> sevation of membership when going from subtype to supertype (i.e.,
> that the proposition "is_member_of_subT => is_member_of_supT"
> is true).

Hi Tak,
  I'm on vacation and don't have my Date books with me, so what I write may not reflect Date's views, but here goes. If there are properties that all values of a given type share, then those same properties must be shared by all values of the subtype. This applies to "methods" as well.

Hi Tak,
  I'm on vacation at the moment and don't have my Date books with me, so what I write may not reflect Date's views, but here goes. Typically, all values of a given type must share some common properties. Types would be next to useless without such. All common properties which are shared by every value of a type must be shared by every value of the subtype. This includes operations.

> I think Date says it quite clearly that operations are not
> automatically inherited.

Not per-se, but there must be a way to implicitly cast from a representation of a subtype to a representation of a type. If you put a circle in a column whose domain is ellipses, then the you may ask the circle for it's foci, eccentricity, etc, just as you could if you had put in an ellipse representation that happened to be a representation of a circular ellipse.

> In other words, his notion of subtype-
> supertype is distinct from that defined by LSP.

Agreed.  

> PD> One might also argue that as a practical matter, one
> PD> _needs_ mutable ellipses and mutable circles. [...]
 

> Note that this difference is independent of the issue of
> mutability of objects. Consider the question of whether { 0, 1 }
> is subtype of Integer . Clearly, ordinary addition is not well
> defined on { 0, 1 } but both 0 and 1 are members of Integer.
> (A similiar problem has been proposed by Mr Martijn Meijering
> in this thread -- whether Integer is a subfield of Rational.)

Clearly ordinary addition is not defined on {0, 1} if you mean that ordinary addition is closed over this set, i.e. that the result lies in this set. However, ordinary addition is clearly well defined on {0, 1}. It just so happens that the results are often outside the set. Let's call {0, 1} "Bit". You can put Bit values in any database column that expects Integers (or Rationals, or Reals) and everything will work as expected.

> From a software engineering (but not necessarily computing
> science) point of view, I think the subtype-supertype
> relationship defined by LSP is a bit more useful than Date's.
> Not all agrees. :-)

Agreed, not all agree :-)

--PeterD Received on Fri Aug 10 2001 - 14:17:55 CEST