Re: Clean Object Class Design -- Circle/Ellipse

On Sun, 5 Aug 2001 00:26:02 -0400, "Bob Badour" <bbadour_at_golden.net> wrote:

>>Once again (from my earlier post):
>> RA is a field, whereas IA is only a ring
>>and thus does nort preserve all properties of RA
>>(existence of multiplicative inverse in particular).
>>
>>Is that enough of a proof that IA is not a subtype of RA
>>(though Date would postulate that it is, since I is a subset of R)?
>
>Assumptions, assumptions, assumptions!!!
>
>Date argues that the type support of the DBMS must allow one to model a
>circle domain as a sub-type of an ellipse domain and you assume he claims
>one MUST model it that way. Likewise, the DBMS must allow one to model an
>integer as a sub-type of real, but that does not require you to do so.

In "Type Inheritance: Is a Circle an Ellipse?" on www.dbdebunk.com Date insists:
"As already indicated, it's my position that a circle categorically is an ellipse in the real world -- to be specific, it's an ellipse in  which the two semiaxes coincide in the radius (equivalently, it's an ellipse for which a=b). In my opinion, therefore, any "model" of inheritance in which type CIRCLE is not considered to be a subtype of type ELLIPSE can hardly be said to be a good model of reality."

Is that a MAY (allow) or a MUST(require)? Hint; what does *categorically* mean?

Worse yet, even MAY without further qualifications is no good.  I have already shown how "allowing" IA to be a subtype of RA results in a a type that does not preserve properties of its supertype.

>If you decide that you want to call something integer such that n+1<=0 for
>some n>0, you have chosen to call something other than an integer by the
>same name. However, n+1>0 for all integer values, n, such that n>0 --
>according to most people's understanding of integer and addition.
>
>The fact that one can define the name Integer to represent a different set
>of numbers and to define the + symbol to have different behavior than
>addition does not prove anything about Date's understanding.
>
>If I want, I can define a number system with the values { 1, 3, +, 7, b }
>and the operators { =, 2 }. Other than mental masturbation, what would be
>the point?
>
>The fact that the DBMS must allow one to create either integer domain such
>that one is a sub-type of real and the other is not does not force anyone to
>do either!

I have not redefined Integers ( or Reals). To the contrary, I have used (undergrad) textbook properties of both sets to show that Date's assumption leads to a contradiction (a type that does not preserve properties of its supertype).
Given, that you got lost at this level, I'm reluctant to recommend B. Nordstrom, K Peterson, and J.M. Smith's "Martin-Lof's Type Theory" for an explanation of the differences between types and sets.

>Your claims regarding Date's understanding of type are extraordinary,
>incorrect and ad hominem. If you are going to make such an extraordinary
>claim, you must provide extraordinary proof, and you have failed to do so.
>Now, put up or shut up!

Ordinary proof will do and I have provided one. In fact I would be first to call my proof elementary, if not trivial. The only reason why I bothered, was to show that Date's assumption leads to a contradiction. (Date's attack on Stroustrup provided the inspiration for the tone of my first post on this topic).

If you'd like more examples of Date's confusion, here's one (from the same article): "To say a circle is a colored circle is like saying a slice of bread is a sandwich"
Nobody ever (to my knowledge) tried to inherit CIRCLE from COLORED_CIRCLE. Stroustrup did not suggest that either. The opposite direction may be perfectly acceptable in some applications (extending black&white graphics program to work on multi-color displays for example).

Marc Gluch
Mindtap Inc. Received on Mon Aug 06 2001 - 07:14:34 CEST