Re: Clean Object Class Design -- Circle/Ellipse

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

The primitives of the subtype/supertype relationship between Real and Integer are Real and Integer.

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

They are not relevant to the issue. This is all just a straw man you constructed. I never made the claim that we had to have a subtype closure on subtype operations, which is absurd on the face of it. I never made the claim that we had to validate subtype relationships using abstract algebras.

Your entire argument is a strawman. It proves nothing about the topic under discussion.

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

You are the one who insists on an inconsistent axiomatization that redefines the semantics of the supertype operations -- not me!

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

Circles also have two coincident foci and as many axes as you want them to have -- including two.

>The funny thing is that in his proposal you inherit
>operations for read purposes, but not update.

One cannot update a value. Update is irrelevant on the face of it. Circle variables are not ellipse variables -- Date acknowledges such. However, circle values are ellipse values. One cannot assign an arbitrary ellipse value to a circle value. One cannot assign an arbitrary supertype value to any subtype value. Does this mean that assignment breaks all subtype/supertype relationships?

Your confusion between update operations on variables with operators on values causes you to reach invalid conclusions regarding Date's essay.

>What does that mean in
>context of numbers, which are immutable

All values are immutable, and all variables are mutable -- regardless of type.

>but clearly one set of propertes is not a superset of the other
>(either way)

According to your straw man -- not according to the actual contents of the essay.

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

You didn't answer the question of the utility of Stroustrup's original essay on the topic. If the definition has no utility, Stroustrup would have no reason to even address it. Neither would any of the other major OO proponents who have tackled the issue.

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

It is an artificial and incorrect limitation you placed on the operators of the subtype in order to construct your straw man. The artificial limitation does not hold for person any more than it holds for integer or any other subtype.

>That's why I picked integers and reals.
>The axiomatizations are well known (apparently not to you)

I understand formalism, and its ultimate futility. I understand that the multiplicative inverse of an Integer is a Rational number, and I understand that the operators on types do not need closure.

Your requirement of closure is a straw man. You can beat it up all you want, but you prove nothing by doing so.

>and I hoped that I wouldn't need to waste time arguing the obvious.

If you understood the obvious, it would obviate the argument.

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

Agreed. And the (Rational or Real) multiplicative inverse of an Integer is also intrinsically mathematical.

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

All axiomatizations exist just as all values exist.

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

Not so. Every statement you made was backed up by a straw man and your own misunderstanding of the essay.

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

I think a colored circle is a decorated circle. How is it not?

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

...by using colored decorations. Your point?

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

A few. We need an abstraction of the device. We need abstractions of the tools for marking up the device. We need an abstraction for a renderable element.

A renderable element has a position and size that the user can manipulate as well as a polymorphic scalable image. I decorate any shape with a pen for drawing its outline. I decorate any closed shape with a brush for filling its interior. The brush could specify a solid color, a hatched color, a bitmap or transparency etc.

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

Are you now claiming that CwWidget is a circle value?

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

I am still waiting for your assessment of why Stroustrup found it a worthy subject to comment on. Or why Bertrand Meyer found it a worthy subject to comment on. Or... Received on Sun Aug 19 2001 - 06:01:55 CEST