Re: Clean Object Class Design -- Circle/Ellipse
Date: Sun, 30 Sep 2001 11:16:31 -0400
Message-ID: <gHGt7.1518$rU1.108932233_at_radon.golden.net>
"James A. Robertson" <jarober_at_mail.com> wrote in message
news:3BB6B750.2010903_at_mail.com...
> Bob Badour wrote:
>
> > "Richard MacDonald" <macdonaldrj_at_att.net> 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
defines
> > "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
> 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
[Quoted] "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.