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

> >>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
for
> > 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
horse
> > 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