Re: Clean Object Class Design -- Circle/Ellipse

On Thu, 18 Oct 2001 20:29:43 -0400, "Bob Badour" <bbadour_at_golden.net> wrote:

>>>>The only "fool-proof" way of deciding if A is a subtype of B,
>>>>that I know, is to treat A and B as formal theories.
>>>>
>>>>The first questions to consider would be:
>>>>Are A and B consistent?
>>>>Does one make more assumptions (postulate more axioms) than the other?
>>>
>>>
>>>Are you arguing that every subtype must postulate more axioms than its
>>>supertype does?
>>Yes.
>>Note that you can't produce the axiomatization of Integers
>>by extending the axiomatization of Reals (or Rationals).
>>You actually would have to drop some axioms.
>
>Which axioms would I have to drop? The axiom that every integer has a real
>multiplicative inverse? I don't agree that I have to.

Axioms of a theory are expressed in terms of primitives of that theory When you say
Axiom MI: For all x =/= 0 in D there is y in D such that x * y = 1 you are talking about some domain D.
For IA = <D, {+.*, = , <}> D is the set of integers and MI holds, for RA, D is is the set of rationals (or reals) and MI does not hold. Are you really unfamiliar with abstract algebras, or just pretending?

>>>>Finally the utility question; can elements of A be substituted for
>>>>elements of B without breaking the theory of B?
>>>Are you arguing that one cannot substitute integer values for real values.
>>>Does this mean that one cannot evaluate (2 * pi) because 2 is an integer
>>>value? If so, how do we relate a circle's radius to its circumference?
>>Sort of. To be exact, I'm arguing that one can't substitute integer
>>function for real/rational function
>
>Substitution of function is not a requirement of subtype/supertype and is
>irrelevant to Date's article on values.
Apparently the consitency of the axiomatizations isn't either, since Date insist that circles are and must be elipses (and poposes a new programming constract "Date's inheritance"), even though circles have one center and one radius, while elipses have two loci and two axes. The funny thing is that in his proposal you inherit operations for read purposes, but not update. What does that mean in context of numbers, which are immutable (my way of getting out of the discussion about whether changing the axis of an elipse is allowed), and in a context of a functional language, that does not have an assignment operation?
dbdebunk seems to be down, so I am unable to give Date's quote, but clearly one set of propertes is not a superset of the other (either way), so by your own interpretation of Date's definition neither one is a subtype of the other, and yet he insist that Circle must be subtype of Elipse.

BTW, you still didn't answer the question of utility of such definition.

>(but after all, given a set of
>>values as parameters, any function is just a non-cannonical
>>representation of some value, and in particular any function of
>>integers, defined in terms of + and *, should produce an integer,
>
>Bullshit. Does every function of Person produce a Person? The Age operator
>results in Person? The Marry operation defined on two Person values must
>result in a Person value? That's not only absurd -- it's the crux of your
>straw man!
That depends how you define Person (remainder, in a context of a programming language, which is dependent on you application needs). That's why I picked integers and reals. The axiomatizations are well known (apparently not to you) and I hoped that I wouldn't need to waste time arguing the obvious.

<snip>
> The Circle-Ellipse issue is intrinsically mathematical, and as such,
> math is the arbiter of what is "the right way" to model Circle and Ellipse. That says
> nothing about "the right way" to model non-mathematical issues such as
>documents.

Integers and reals are as "intrinsically mathematical" as circles and elipses.

>>Definition subtype = subset may be (and probably is) right
>>in the db world. It is not so in the programming world.
>
>This is a definition you made up to construct your straw man. It is neither
>my definition nor Date's definition nor any other person's definition of
>which I am aware.
This is my conclusion from Date's assertion that circle type is a subtype of elipse type regardless of axiomatization of each type.

>
>>Perhaps you can help me see the benefits that Date brings
>>to the programming table.
>
>Start by limiting your analysis of Date's essay to the content that Date
>actually puts in it without embellishing it from your own imagination.
So far every statement I made was backed up by a quote from the article.

<snip>

>By what principle of design does programming language theory suggest to one
>to model colored_circle using inheritance rather than role or delegation?
By principle of shared behavior. Are you suggesting that COLORED_CIRCLE should have a reference to CIRCLE, and delegate 75% of its responsibilities? What do you gain going that route? Think before you type.

>In what application domain would one choose to model colored_circle as a
>subtype of circle?

I already gave you a likely scenario in one of my previous posts. I graphics application written for monochrome displays can be easily extended to work on color displays.

>In a drawing program, for instance, I am unlikely to choose such a design. I
>am much more likely to use decoration than inheritance.
You must be joking. How many drawing programs have you written? It took me 10 seconds to do a search on *color* in VA Smalltalk to find CwComposite which is a subclass of CwBasicWidget (itself a subclass of CwWidget) and has such attributes as xmNbackgroundColor and xmNforegroundColor.

I am still waiting for your assessment of the benefits of Date's definition.

MArc Gluch
Mindtap Inc. Received on Sun Aug 19 2001 - 04:04:15 CEST