Re: Clean Object Class Design -- Circle/Ellipse

"Marc Gluch" <marc.gluch_at_mindtap.com> wrote in message news:3b7fbfc7.3735066201_at_news.grpvine1.tx.home.com...
> On Sun, 19 Aug 2001 04:54:53 GMT, "Richard MacDonald"
> <macdonaldrj_at_att.net> wrote:
>
> >Marc, what is the point of this?
> 1. Comparison of utility of Liskov definition of subtype
> (substitutable behavior) vs Date definition.
>
> Simpler yet, comparison of Stroustrup vs Date.
> I am unable to bring up Date's article on dbdebunk.com,
> and I don't want to "quote" from memory, so let's try this:
>
> Take C++ (no role model, but that's what the article refers to)
> Remove Stroustrup inheritance.
> Add Date "inheritance" (however he defines it)
> Call the new languge C+- ;-).
>
> What are the benefits of C+- over C++ ?
>
> If you don't like the C++ context, then:
> how is Date's definition any more useful than Stroustrup's
> in a context of any programming language?
>
> 2. Since polymorphism is not set-theoretic,
> subtyping and substitutability are best confined to
> abstract types. It is then the responsibility of each abstract type
> to define conversion rules (if any) among its (possibly many)
> concrete implementations.

Which they do.

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

> 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 :-) Received on Sun Aug 19 2001 - 18:40:03 CEST