Re: Clean Object Class Design -- Circle/Ellipse

>>>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."

First, you need to recognize what Date discusses above. He explicitly discusses VALUES. Whether you declare a circle or ellipse type in your database has no affect whatsoever on the values of circles and ellipses.

Assuming that the '^' symbol represents exponentiation, consider the following numeric value: 10^10^10^10^10^10^10^10

I can represent the value easily enough just as I did above; however, I cannot count that high. In fact, I am fairly certain the universe lacks sufficient states to count that high.

The number I represented above is an integer. It is also a rational and a real.

* I can add 1 to it: 1+(10^10^10^10^10^10^10^10)
* I can multiply it by pi: pi*(10^10^10^10^10^10^10^10)
* I can square the number: 10^10^10^10^10^10^10^20
* I can calculate the square root: 10^10^10^10^10^10^10^5
* I can calculate the area of a circle with such a radius:

    pi*(10^10^10^10^10^10^10^20)

Can either you or Martijn describe an operation that applies to all real numeric values that does not apply to the above numeric value? Can either you or Martijn describe an operation that applies to all real numeric values that does not apply to all integer numeric values? Can either of you describe an operation that applies to all rational numeric values that does not apply to all integer numeric values?

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

It is MAY (allow). I sincerely doubt that many databases will have a numeric domain to represent integers, rationals or reals that will ever represent the value 10^10^10^10^10^10^10^10.

Whether we model integer as a subtype of real in the DBMS has no affect whatsoever on numeric values or on the operations that apply to them. Integer categorically is a subtype of real, regardless. Circle categorically is a subtype of ellipse, regardless.

>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.

Your IA/RA example is a straw man. You start by excluding the operations that apply to both reals and integers from the set of operations you allow one to apply to integers.

If you define multiply and divide operations that operate on reals to give real results, they will equally operate on integers to give real results. The multiplicative inverse of 2 is 0.5, and both of these values are reals. One of these values is also an integer.

If you declare a RealNumber object class to your database that includes multiply and divide operations, you can easily and safely declare a subclass, IntegerNumber, that implements all of the RealNumber operations. Of course, since the base class requires that multiply and divide result in RealNumber object values, the corresponding (or overridding) IntegerNumber operations must result in RealNumber object values as well.

Of course, this does not prevent one from declaring additional multiply and divide operations that always result in IntegerNumber values, but those additional operations have different semantics and rules. They apply to the subclass and not to the base class, which causes no problem whatsoever.

>I have not redefined Integers ( or Reals).

In fact, you have. All Integers have a Real multiplicative inverse. You have redefined Integers to have no multiplicative inverse.

>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.

If the text requires us to redefine Integer to have no Real multiplicative inverse, I doubt I would find much use in it, in any case.

>>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.

No, you have not provided one. You have constructed a straw man, and I would be the first to call it trivial, if not petty.

>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).

Date did not attack Stroustrup. He simply used the content of Stroustrup's book as a reasonable, respected, published exemplar of the counter argument.

>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.

Stroustrup: "[circle and ellipse] typically have additional properties (such as color and associated text)"

Stroustrup did not suggest that CIRCLE is derived from COLORED_CIRCLE; he simply suggested, for expediency, that CIRCLE has the properties of COLORED_CIRCLE without declaring COLORED_CIRCLE.

Remember that Date discusses VALUES in his essay. He makes the valid point that the drawing program uses circle values, color values and text values. The combination of circle value, color value and text value is itself a value that is neither a circle, a color nor a text.

Again, I don't see how any of this supports your ad hominem that anything confuses Date.

>The opposite direction may be perfectly acceptable in some
>applications (extending black&white graphics program to work on
>multi-color displays for example).

This is precisely Date's point! A circle is not a colored circle; although, a colored circle combines the properties of a color with the properties of a circle. A slice of bread is not a sandwich; although, a sandwich combines the properties of one or more slices of bread with the properties of one or more fillings.

To put it bluntly, Date is not the confused person. Received on Sat Aug 18 2001 - 15:54:32 CEST