Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Clean Object Class Design -- Circle/Ellipse

Re: Clean Object Class Design -- Circle/Ellipse

From: James A. Robertson <>
Date: Sun, 30 Sep 2001 15:30:52 GMT
Message-ID: <>

Bob Badour wrote:

> "James A. Robertson" <> 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.
  2. Why does it matter in any way?


>>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
>>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. Basically, you are arguing a dry academic point that has no relevance to software development.

I think I know who the troll is; it's not MacDonald...

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

Heck, subclassing should be used sparingly anyway.

> 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 find it telling that you worry about this at all. Go do some system development and see how often this problem actually arises.

Received on Sun Sep 30 2001 - 10:30:52 CDT

Original text of this message