Re: Clean Object Class Design -- Circle/Ellipse

"Marc Gluch" <marc.gluch_at_mindtap.com> wrote in message news:6c9a2e10.0108210711.66f84b1_at_posting.google.com...
> "Richard MacDonald" <macdonaldrj_at_att.net> wrote:
>
> > Lousy word on my part. Having the result of an operation be a
> > type unrelated to the argument type. The age of a Person
> > is an Integer. Person and Integer are not related types.
> They don't have to be.
> A generic function is "typeless", e.i. of a type: Type -> Type (so to
 speak).
> Input and output don't have to be the same type.
> Such function defines a relationship between the input and output
> that is independent of the concrete type of input and output.
> Another, perhaps more accurate way to explain it is to say
> (per Liskov) that an abstract type is a set of operations
> (you can't instantiate an abstract type).

Ok with all this.

> > > The way I prefer to put it is to say that
> > > one specialization/implementation should not redefine another.
> > > They all should be (parallel) implementations of a generic
> > > (ala CLOS) function.
> > >
> > Ok, but this confuses me. You seemed to be trying to
> > build up the type theory strictly from axioms ...
> Yes

Axioms where the function inputs and outputs *are* the same type?

> > that were limited to staying "within" a type hierarchy.
> The phrase "stay within" in some subtle way rubs me wrong.

Me too. I lack the theoretical terminology. That was the best word I could come up with and I didn't like it either.

> I feel more comfortable saying that the additional axiom(s)
> need to be consistent with those of the supertype (parent theory).

Seems obvious :-)

> >The above statement does not have this limitation.
> Perhaps my original explanation was incomplete.
> Does the current (generic/Liskov) elaboration help?

Perhaps I should explain. I understand Liskov but I don't have the terminology that you guys do. Awhile back, you seemed to be trying to build up from an axiom where the input and output type was the same. This caused Bob's comment about asking a Person his/her age. It confused me.

> In my Smalltalk example:
> Magnitude introduces the (generic) concept of order: {<}.
> Number introduces the generic concept of arithmetics: {+,*}.
> Integer, Fraction and Float are concrete types (i.e realizations)
> of the abstract supertype. There are plenty of morphisms among them,
> but that doesn't mean that one type is a subtype of another.
> Because they are realizations (implementations),
> you can always find a property that makes them inconsistent.
> That property is ... representation.
> The supertype must mitigate such inconsistencies
> by defining the axioms of conversion (casting).

Sounds completely reasonable.

Is there anything to be gained by using the axiom where input and output types are the same, then viewing it from a generic function's perspective where the type is Object, i.e., all-encompassing? Received on Tue Aug 21 2001 - 21:42:25 CEST