Re: Clean Object Class Design -- Circle/Ellipse

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

> >> To begin with, I only ask that set set of axioms of the supertype
> >> be a subset of the set of axioms of the subtype (wrt the standard,
> >> FOL disjunctive normal form representation of these axioms),
> >> and only for abstract types. That result is the same type
> >> as arguments is just a consequence of that requirement
> >> (for operations that produce values of the supertype)
> >> in combination with the closure axiom.
> >>
> >> Note: I also ask that the two axiomatizations are consistent,
> >> meaning not every constraint is an axiom.
> >>
> >> Once you are down to concrete classes, they are not subtypes
> >> but rather implementations of the abstract type.
> >> They are not (directly) substitutable for one another --
> >> the abstract supertype defines the conversion axioms.
> >>
> >> Another (side) point:
> >> Given choice (knowledge, time, and materials), one should
> >> use composition rather than inheritance (for example
> >> construct rationals from itegers, not the other way around).
> >
> >That would be nice. The Smalltalk Fraction class does this.
> >Integer and Fraction are still subclasses of Number, though.
> >And you're still going to have to define some of your Integer
> >operations to answer Rational/Fraction. How are you going to
> >do this? (Pardon my density :-)
> 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. Received on Sun Aug 19 2001 - 23:07:08 CEST