Re: Clean Object Class Design -- Circle/Ellipse

On Sun, 19 Aug 2001 21:07:08 GMT, "Richard MacDonald" <macdonaldrj_at_att.net> wrote:

>"Marc Gluch" <marc.gluch_at_mindtap.com> wrote in message
>news:3b801b09.3758364652_at_news.grpvine1.tx.home.com...
>> On Sun, 19 Aug 2001 16:40:03 GMT, "Richard MacDonald"
>> <macdonaldrj_at_att.net> wrote:
>>
>> >
>> >> > An axiom limited to functions where the
>> >> >argument and result are the same type
>> >> >isn't any good for building a type theory.
>> >>
>> >> Actually, it is. It guarantees LSP.
>> >
>> >In a uselessly limited version? If I can't ask a Person for his/her age,
>> >what's the point? Or are you also trying to derive this extension from
>> >the axioms?
>> Did you read the paragraph following this statement?
>
>Read is not the same as understood :-) You guys are in rarified air.
>
>> Age does not
>> produce values of the supertype (IOW it is not a polymorphic operation
>> between Person and some sublcass of Person). You can inherit it,
>> unless the sublass requires a different (inconsistent) interpretation.
>
>I guess I don't understand this interpretation of "polymorphism".
>I read the above as restricting polymorphic operations to map from argument
>type to result (same) type, which you couldn't be meaning.
>
>Never mind. You're busy enough tackling the other issues without being
>slowed down by me. I'll try to follow quietly. . .
Not to worry... I just managed to mow my lawn.

Polymorphism is about composability (IMO). LSP is asking that

       fg = fg', hf=h'f
 and so on for all other possible combinations of functions defined in the supertype and their overriden (primed) versions, i.e. commutativity of composition and interpretation.

The overriding version doesn't have to produce the same type of value as the original, overriden version, but it can't change the final result.

<snip>
>> Not in the Integer class, but in Number (where these signatures
>> belong) and in Rational or Real (where their implementations belong).
>> with Number dispatching the computation to appropriate subclass.
>>
>Ok, so you're moving the type definition "up" the type hierarchy to
>where the argument/result types "encompass" the domain of the
>type. Operations in Number return Number. The subclass
>implementations are free to restrict this further according to LSP.
>I'm not sure how to tackle Number operations that don't return
>Number (e.g., lessThan) according to your axiom restrictions,
>but I'll read along.
I think I mentioned it in some earlier post. Magnitude provides axiomatization of the ordering relationship ("<"). Number (derived from Magnitude) overrides "< " appropriately for its domain.

Marc Gluch
Mindtap Inc. Received on Mon Aug 20 2001 - 00:34:05 CEST