Re: Clean Object Class Design -- Circle/Ellipse
Date: Mon, 8 Oct 2001 04:23:24 -0400
Message-ID: <codw7.733$Qc7.28459036_at_radon.golden.net>
"Richard MacDonald" <macdonaldrj_at_att.net> wrote in message
news:z5Qv7.33509$WW.2163789_at_bgtnsc05-news.ops.worldnet.att.net...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:cd3b3cf.0110061710.60f86f60_at_posting.google.com...
> > brangdon_at_cix.co.uk (Dave Harris) wrote in message
> news:<memo.20011001000009.35593A_at_brangdon.madasafish.com>...
> > > bbadour_at_golden.net (Bob Badour) wrote (abridged):
> > > > Ask him to point to any Smalltalk language definition that defines
> > > > "instance" as anything other than a variable which one can
reference.
> > >
> > > The 1997 draft of the ANSI Smalltalk standard (which is the version of
> the
> > > standard I have to hand), says:
> > >
> > > A /variable/ is a computational entity that stores a single
> > > reference (the /value/ of the variable) to an object.
> > >
> > > [...] An /object/ is a computational entity which is capable of
> > > responding to a well defined set of messages. An object may
> > > also encapsulate some (possibly mutable) state.
> > >
> > > This is *not* saying an object is a variable.
> >
> > "reference to an object" implies that "object" is variable.
>
> Nope. It implies that the reference is the variable. It says
> nothing about the object itself.
Au contraire. It says that the object (variable) can be referenced. One cannot reference a value; one can only reference a physical location (variable) that encodes some representation of a value.
> > Values are
> > self-identifying and one cannot reference a value. One can reference
> > storage or memory that contains some representation of a value, but
> > storage and memory are variable. That a variable is constrained to a
> > single value for some period of time does not change its nature.
>
> Even when that particular variable *cannot* change, i.e., is
> indistinguishable from a value.
All variables change at some time or another. At some time, the memory or storage contains a different value.
Applying a constraint to a variable makes a constrained variable and not a value. If you attempt to alter a constrained variable in such a way as to violate the constraint, an error occurs.
In the case of a variable constrained to a single value, the argument against the subtype relationship disappears; if the constrained ellipse variable containing a circle value receives the setFoci message with different foci, it must signal an error since this would violate the "unchanging" constraint.
However, I suspect Smalltalk gets this wrong and probably allows one to change variables one considers constant.
> Well, you're consistent at least.
> Incomplete theory though.
So you claim, but I think you just haven't thought the implications through to their logical conclusions. Of course, that doesn't surprize me since you earlier admitted less than exemplary motivation.
> > That's not to say that no such thing as an object value exists. Object
> > value is an important concept just as object variable is an important
> > concept.
>
> Oh please, tell us more.
Your sarcastic tone is at least consistent with your prior admission that your interest is in attacking and in destroying rather than in learning or in communicating:
> I'm just exercising a
> particular set [of prejudices] now since your high horse
> is flimsy and you deserve to be taken down a notch.
As I said at the time, what you call my high horse is not at all flimsy.
> > If you had included a little more from the standard where it defines
> > /message send/ and explains that "Each argument is a reference to an
> > object", you would see that Smalltalk requires a variable in order to
> > send a message. In other words, Smalltalk only pretends to have values
> > and requires one to store a representation of a value in a variable
> > prior to doing anything.
>
> No again. Same point as above. The reference (attribute) is the
> variable. This says nothing about the object being referenced.
Au contraire. It says one can reference the object (variable). One cannot reference a value.
> 5 squared.
>
> I just don't see the variable there.
The squared method returns a reference to a variable. Just as the world does not disappear when the proverbial ostrich sticks its head in the sand, the variable does not disappear when you ignore it or deny it.
> Unless, like you, I make one up
> and wrap it around the value 5 to make my theory consistent.
I don't make one up. The ANSI Smalltalk standard does:
Section 3.1 Computational Model of Smalltalk Execution (paragraph 8):
A return terminates execution of a method and causes execution to resume within the method that executed the message send that activated the method containing the return. Execution continues immediately following the message send expression. The return provides a value (an object reference) that becomes the value of the message send.
Any programmer, who appreciates the differences between variables and values, will note that the value returned from every method is a reference to a variable.
> > > (The ANSI standard does not define "instance". It uses "object"
instead.
> > > Later it says that when an object does have state, it represents it
with
> > > special kind of variables called "instance variables". In other words,
> an
> > > object is not a variable but an object can contain variables.)
> >
> > How does one change part of something that cannot change?
>
> One doesn't. One cannot change the SmallInteger 5.
Of course not, a variable (object instance) constrained to the value 5 cannot change, and the value 5 cannot change.
> > > > An instance or variable can have the value 5. The value, however, is
> > > > not an instance.
> > >
> > > So sorry, but in Smalltalk the value 5 is an instance of the class
> > > SmallInteger.
> >
> > Untrue. An instance of the class SmallInteger can contain a
> > representation of the value 5, but the value 5 is not an instance of
> > anything. I realize that Smalltalk confuses things by requiring
> > variables for messaging and then pretending that variables are values.
>
> I see your philosophy now. Values are only within God's domain.
> Everyone else must deal with representations.
Histrionics aside (and I am an atheist), have I not made it abundantly clear that values exist apart from representation?
Smalltalk, by requiring a variable (instance) for messaging, has caused you to confuse variables (instances) with values, which confirms my original contention.
> > > > One cannot reference a value. Values are self-identifying.
> > >
> > > Indeed 5 is self-identifying. We can send a message to the value 5
> whether
> > > or not we have a variable referring to it.
> >
> > Yes, I agree that one can have operations on values. These are, of
> > course, different from update operations on variables. Have you not
> > seen me state that previously?
>
> No we haven't.
Really? You started this subthread when you replied to one of my posts in a dialog I was having with Dmitry Kazakov. You may recall your reply as the one where you made the absurd claim Smalltalk has instances that are values. You replied to a message where I wrote the following:
"Since the subtype has all of the properties of the supertype, any operation defined on Ellipse values can operate directly on Circle values without conversion."
and where I excerpted the following from one of my prior messages in the dialog with Dmitry:
"Have you considered that one must apply LSP separately to variables and values. Values do not change -- ever. Variables do change. This makes them very different things."
> We've been showing you examples of operations on
> values and you've been telling us we're fooling ourselves.
You have been claiming that some instances are values, which is a very different claim. The definition of Smalltalk requires variables (instances) where they are not strictly needed, which causes you to confuse variables (instances) with values.
In the case of Smalltalk, all operations operate on variables even when the programmer intends an operation on a value. Given an operation on a literal: the language creates a variable, stores a representation of the value represented by the literal and sends a message to the variable. Because the variable Smalltalk creates is an instance, you have confused the instance with a value.
This, of course, confirms my earlier claim that Smalltalk makes insufficient distinction between values and variables.
> > Of course, the Smalltalk standard
> > requires all implementations to operate only on variables.
>
> Of course :-)
> Luckily it allows me, the programmer, to pretend I'm actually
> working with values.
While you can pretend all you want, instances are variables and are not values.
> > > Perhaps you are talking about some other language, also called
> Smalltalk?
> >
> > No. I just read with a little extra care and a little better
> > understanding of the concepts involved.
>
> And a religion.
I am a devout atheist. While the prejudices that motivate you to attack resemble those of religious zealots, I would stop short of concluding that you actually worship Smalltalk. Received on Mon Oct 08 2001 - 10:23:24 CEST