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: Bob Badour <>
Date: Sun, 30 Sep 2001 11:16:31 -0400
Message-ID: <gHGt7.1518$>

"James A. Robertson" <> wrote in message
> Bob Badour wrote:
> > "Richard MacDonald" <> wrote in message
> >>>
> >>I know Smalltalk more than a little well.
> >>And James Robertson (who knows a thing or
> >>two about Smalltalk :-) agreed with me that you
> >>were incorrect.
> >>
> >
> > Big deal. Ask him to point to any Smalltalk language definition that
> > "instance" as anything other than a variable which one can reference.
> >
> Object new
> no variables there - one instance of Object. Variables in Smalltalk are
> either:
> instance variables
> class variables
> class instance variables
> Pool Dictionaries
> method temporaries
> block temporaries
> method args
> block args

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.

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

> >>Why not simply argue your way out of the previous 3
> >>sentences?
> >>
> >
> > They were untrue. Anyone with access to a browser and Google can verify
> > themselves that Smalltalk defines "instance" as a variable that one can
> > reference.
> an instance is an object in memory - I may or may not have a variable
> that references it. Either way, why is it of any importance?

An object in memory is a variable that one can reference, which is a different type from the value it contains. As explained above, this has importance to the topic of discussion: type inheritance. Whether any other variable references the variable is of little import except during garbage collection, which is not a topic I have any desire to discuss on comp.databases.theory; athough, you are welcome to pursue that discussion on comp.object without me.

> >>Oh I have lots of prejudices like we all do. I'm just exercising a
> >>particular set now since your high horse is flimsy and you
> >>deserve to be taken down a notch.
> >>
> >
> > As I said previously when you posted the above: What you call my high
> > is not at all flimsy. You expose much
> > about yourself and your motives in the above statement. You expose,
> > for instance, that you have no interest in learning or in
> > communicating -- instead, you have an interest in attacking and
> > destroying. I find little merit in your goals.
> 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.

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. Received on Sun Sep 30 2001 - 10:16:31 CDT

Original text of this message