Re: Clean Object Class Design -- Circle/Ellipse

>>Marc, what is the point of this?
>1. Comparison of utility of Liskov definition of subtype
>(substitutable behavior) vs Date definition.

Date does not change LSP. His essay only observes that one must apply LSP separately to variables and values. Circle values are always substitutable for ellipse values. Integer values are always substitutable for rational or real values.

If one does not apply LSP separately to variables and values, assignment itself prevents any form of inheritance.

>What are the benefits of (Date's description of inheritance) over C++'s ?

Date's description is an observation of the concept as it is. C++'s imposes limiting artifacts preventing natural reuse and polymorphism.

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

Date's definition allows one to polymorphically reuse natural subtypes and obviates the excuses Stroustrup and others must make for the failings of their languages.

>2. Since polymorphism is not set-theoretic,
>subtyping and substitutability are best confined to
>abstract types.

All types are abstract and have multiple representations.

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

It prohibits inheritance and almost every useful operator known to mankind. How is that useful for building a type theory?

>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

This is trivially so. For instance, the axiom that all reals have real multiplicative inverses applies to integers. You constructed a straw man by omitting the axiom.

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

The closure axiom is not required. You added it solely for the purpose of constructing your straw man.

>Once you are down to concrete classes, they are not subtypes
>but rather implementations of the abstract type.

All types are abstract -- including integer and real.

>They are not (directly) substitutable for one another --
>the abstract supertype defines the conversion axioms.

Um, wouldn't conversion break closure? Not that I ever claimed closure was required or anything, mind you.

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

Representation is orthogonal to type. Received on Sun Aug 19 2001 - 18:16:49 CEST