Re: Circles and ellipses

> >But let's return to cicle/ellipse for a minute? Why would anyone WANT to
> >consider a circle an ellipse? Well, I can see one immediate benefit: if
> >all the relevant operations that work on an ellipse also work on a circle,
> >then you can get more useful software written by construing a cirlce as a
> >specialized ellipse, and not writing an implementation for a whole
> >different class.
>
> Granted.
>
> Now, consider that Ellipse has the following method:
>
> public setFoci(Point f1, Point f2);

The key distinction in Date's article is such an update operation necessarily applies to variables and not to values.  

> This would be inherited by Circle.

Since values cannot change, no circle value (or any ellipse value for that matter) would inherit the update operation.

> Circle can't tolerate two foci, so
> the implementation of this function in Circle would have to ignore one
> of the two foci. This is wierd.

It can tolerate two foci as long as the two foci are coincident, in which case you have a circle value regardless of representation.  

> To make matters worse, some client of Ellipse could call setFoci and
> fully expect that the excentricity of the resulting ellipse to reflect
> to two foci. If a circle is passed to this client, his expectation
> would be violated.

Since the client can only apply an update operation on an ellipse variable, it should not matter whether the value prior to the update operation is a circle and the value after the update operation is not a circle. In both cases, the value is an ellipse, which is valid for the variable's declared type.

> This is the essential problem that the LSP (Liskov Substitution
> Principle) tries to resolve; or at least identify.

If one treats values and variables as the same thing, then LSP guarantees that no inheritance is valid unless every subtype is a superset of the values of the supertype, but we already know that a subtype is a subset of the values of the supertype. This would require equivalent sets of values for all types related in any way through inheritance.

> Clients of a base
> class can be confounded by certain derivatives that appear natural.

The derivations are natural provided the language makes proper distinctions between variables and values.

> Circle is a natural derivative of Ellipse but can confound clients of
> Ellipse.

Only in languages that make no distinction between values and variables.

> This implies that the "naturalness" of the derivation is not
> useful.

I would argue that the lack of distinction between values and variables reduces utility -- not the naturalness of the derivation. The utility impairment should be a clue that the lack of such distinction is harmful. Received on Wed Aug 22 2001 - 14:40:15 CEST