Re: Clean Object Class Design -- Circle/Ellipse

"James A. Robertson" <jarober_at_mail.com> wrote in message news:<3BC59460.3090400_at_mail.com>...
> Bob Badour wrote:
>
> > "James A. Robertson" <jarober_at_mail.com> wrote in message news:<3BC199E9.8020103_at_mail.com>...
> >
> >>Use one I'm actually likely to stumble on in a real application I might
> >>write.
> >>
> >>Bob Badour wrote:
> >>
> >>
> >>>Using the real example of circle and ellipse:
> >>>
> >>>How does Smalltalk:
> >>>* allow me to declare circle as a subtype of ellipse?
> >>
> >>I subclass Circle from Ellipse
> >>
> >>>* allow me to send the setFoci message to ellipse variables (that
> >>>incidentally contain circle values) with two different focal points?
> >>
> >>I override the methods in the subclass so that each gets appropriate
> >>behavior. If the ellipse variable contain circle values, ,my
> >>application code is wrong>
> >
> > Are you saying that Smalltalk does not allow polymorphism?
>
> How does that follow from anything I said?

If Circle is a subtype of Ellipse, Ellipse variables can contain Circle values.

> I could just as easily have
> declared Ellipse to be subclassed from Object and supported the same
> protocol.

What does the supertype of Ellipse have to do with whether Ellipse variables can contain subtype values?

> >>>* prevent me from sending the setFoci message to circle variables?
> >>>
> >>See above.
> >
> > Overriding setFoci does not prevent me from sending the message, does
> > it?
>
> No, but I can override it in such a way as to make it irrelevant -
> raising an exception, for instance.

In a weakly typed language like Smalltalk, I suppose that is as much as we can hope for. However, I see little utility in weakly typed languages -- especially for database management.

> If the developer using the new
> class doesn't know how to use it, that's not really my problem, is it?

If you are modelling types for a database, it is.

> >>If I find that I'm overriding enough methods, subclassing was a bad
> >>choice. You have created an example 'problem' that isn't much of a
> >>problem.
> >>
> >
> > If Smalltalk made sufficient distinction between values and variables,
> > one would not need to override setFoci in the Circle class because it
> > would never inherit the method. Circle values would inherit the
> > operations on Ellipse values but Circle variables would not inherit
> > the operations on Ellipse variables.
>
> If you understood Smalltalk, you wouldn't make such egregious errors in
> your postings either. Have you ever used Smalltalk? From what vast
> well of experience do you draw your silly statements from?

What egregious error? While several people have made this bold claim, nobody has yet demonstrated a single one. Received on Thu Oct 18 2001 - 02:20:53 CEST