Re: Clean Object Class Design -- Circle/Ellipse

"Marc Gluch" <marc.gluch_at_mindtap.com> wrote in message news:3b80347b.3764879580_at_news.grpvine1.tx.home.com...
> 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.
>
Got it. You moved that up a little higher again. (I am a Smalltalker.) I'm still lost on the issue of the operations that "jump outside" the argument's domain. Are you saying that any operation that does so must move up the hierarchy until it encompasses both the argument and the result? So you disallow the "jump"? Received on Mon Aug 20 2001 - 05:19:30 CEST