Re: Clean Object Class Design -- Circle/Ellipse

"James A. Robertson" <jarober_at_mail.com> wrote in message news:<3BB73A9B.6020306_at_mail.com>...
> Bob Badour wrote:
>
> > "James A. Robertson" <jarober_at_mail.com> wrote in message
>
> > In Smalltalk, all named variables contain references to dynamically
> > allocated variables. An instance of Object is a dynamically allocated
> > variable in memory. As an aside, the type of all named variables in
> > Smalltalk is reference to a reference to a value representation. The type of
> > the value contained in all named Smalltalk variables is a reference to a
> > value representation, which is of course different from the type of the
> > named variable.
>
> 1) You are using the term 'variable' differently than everyone else.
> This is at least going to cause confusion.

"That which changes": Are you honestly telling me that everyone else means something different?

Programmers understand concepts such as: global variable, instance

variable, automatic variable, dynamically allocated variable, local
variable, class variable, object variable, temporary variable, simple
variable, reference variable, etc.

> 2) Why does it matter in any way?

Proper handling of subtypes, for a start.

> >>do you see any variables in the expression above that creates an instance?
> >>
> >
> > Yes, I do. The instance itself is a variable dynamically allocated in
> > memory.
> >
> >
> >
> >>>According to the definition of the Smalltalk language an instance is a
> >>>variable that one can reference. One cannot reference a value. Values
> >>>
> > are
> >
> >>>self-identifying.
> >>>
> >>>
> >>>
> >>
> >>Sigh. You are being extremely pedantic. Explain how your definitions
> >>relate to anything useful. Then, find me an actual use of them that
> >>relates to Smalltalk.
> >>
> >
> > They relate to the topic under discussion: type inheritance. Because a
> > variable is a different type than a value, Circle value is a subtype of
> > Ellipse value while, at the same time, Circle variable is not a subtype of
> > Ellipse variable. When people argue that Circle is not a subtype of Ellipse,
> > they invariably apply LSP beyond its proper scope by assuming that values
> > and variables are the same type.
> >
> > The statements above apply equally to all subtype/supertype relationships
> > between a subtype value, SUBV, and a supertype value, SUPERV. A SUBV value
> > is a subtype of SUPERV value while, at the same time, SUBV variable is not a
> > subtype of SUPERV variable.
> >
> > When someone argues that SetFoci or SetMajorAxis operations violate LSP,
> > they ignore the fact that such update operations necessarily operate only on
> > variables. ie. They do not apply to values, which cannot change.
> >
> > In any language that makes proper distinction between variables and values,
> > the alleged problems with type Circle inheriting type Ellipse disappear. The
> > OO pundits that argue against such an inheritance merely demonstrate that
> > their favourite language makes insufficient distinction between value and
> > variable -- Smalltalk included.
> >
> > As it happens in another sub-thread, a Smalltalk bigot called C++ crappy,
> > and I observed that all current OO languages are about as crappy as C++. I
> > asked "Why not Smalltalk?" Smalltalk pundits incorrectly argue that Circle
> > is not a subtype of Ellipse. Smalltalk makes insufficient distinction
> > between values and variables. Given that the product manager for a smalltalk
> > implementation has the confused idea that instances are (or can be) values
> > proves the point.
> >
> > Variables can contain the representation of some value, but variables are
> > not values. Variables change; values do not.
> >
> > If one applies the SetMajorAxis operation to an ellipse variable that
> > happens to contain a circle value, the language should allow the operation
> > regardless. After the operation, the variable still contains an ellipse
> > value, which is a valid value for the ellipse variable, even if it is no
> > longer a circle value.
> >
> > Mr. MacDonald, the troll who hijacked the thread with the absurd claim that
> > "Smalltalk *has* instances that are values", has already admitted that his
> > motives were to attack without attempting to learn or to communicate. I do
> > not know why you would want to take up his cause.
> >
> >
>
>
> So the premise of all those words is that I can't subclass Circle from
> Ellipse in Smalltalk and properly replace it?
>
> First, if I create a subclass, I override any methods no longer work
> properly. There is no problem here for a <competent> software
> developer.

I guess that Bjarne Stroustrup, Bertrand Meyer, Jim Rumbaugh are not <competent> software developers, in that case.

When you override the setFoci method defined in Ellipse for Circle, what differences would you implement?

> Basically, you are arguing a dry academic point that has no
> relevance to software development.

What criteria determine when to inherit? What guidelines would you recommend?

> >>I find little merit in your definitions. They don't relate to solving
> >>any real problems in development; they don't relate to any useful
> >>information at all.
> >>
> >
> > Au contraire, subtype/supertype relationships arise in many, if not most,
> > real problems in development. Any language that prohibits the user from
> > modelling natural subtype/supertype relationships such as Circle/Ellipse
> > interferes with development. For any such language, all inheritance will be
> > arbitrary, ad hoc and unrelated to either the problem domain or the solution
> > domain. No developer will ever have objective guidelines for when to use
> > inheritance vs. roles, delegation etc.
>
> Funny how this never seems to come up as an issue in system development
> then. When subclassing, one overrides methods as needed.

Really? If that is the case, why do I find so many articles on delegation, roles, LSP, and even the circle/ellipse dilemma?

> Heck, subclassing should be used sparingly anyway.

More to the point, when should one use it at all?

> > I find it very telling that almost every OO pundit has found it necessary to
> > write an apologia explaining why the very real and natural subtype/supertype
> > relationship between circle and ellipse does not apply in OO.

>

I develop software professionally. I develop systems all the time using object oriented programming languages. I don't know of any overriding need for type inheritance at all, if not for natural subtype relationships. When would good programming practice suggest to use inheritance, if not for natural subtype relationships? Received on Sun Oct 07 2001 - 01:07:15 CEST