Re: Clean Object Class Design -- Circle/Ellipse

brangdon_at_cix.co.uk (Dave Harris) wrote in message news:<memo.20011008212902.61375B_at_brangdon.madasafish.com>...
> bbadour_at_golden.net (Bob Badour) wrote (abridged):
> > The reference identifies some location that at one time
> > contained the representation of a different value than the
> > representation it now contains.
>
> No it doesn't.

Let's see if I can decipher what you are saying. Are you claiming that the reference identifies some location that has contained the representation of the same value since the big bang?

> > What Smalltalk calls a variable is generally a named variable. The name
> > itself is a reference to a location in memory or an offset within a
> > variable.
>
> Agreed.
>
>
> > The value represented at that location or offset is itself a
> > reference to a variable.
>
> No, it isn't, necessarily. It may contain an instance directly.

Not according to the ANSI definition of the language. The value at that location or offset is itself a reference to a variable. The variable referenced by that value might, finally, be an indexed array of bytes.

> > Smalltalk also allows two kinds of indexed variables for abstract
> > pointer-based access. Each indexed variable contains either an indexed
> > array of bytes or an indexed array of references to variables.
>
> Note that a "byte" is an integer constrained to the range 0-255. In other
> words, an object.

I don't recall the standard specifying that "byte" is an object anything.

> > If anthing refers to the thing by an address, it tells us that the
> > thing is a variable. It does not tell us whether the value the thing
> > has is a pointer to another variable, but if the thing is referred to
> > by address, it must be a variable that has a value.
>
> Agreed.
>
>
> > In Smalltalk, after the assignment, the variable denoted by 'a'
> > contains a reference to a variable that stores a representation
> > of the number 5.
>
> Sorry, but this is just wrong. The variable denoted by 'a' will contain a
> representation of the number 5. It will not contain a pointer or reference
> to a location containing 5.

Not according to the standard. All named variables are references to variables. The variable (ie. memory location) denoted by 'a' will contain a reference to a memory location where a representation of the value 5 is stored.

> > "Attachment" was only an artifice used to obfuscate the issues.
>
> For the record, I varied the terms in order to be more precise, more
> accurate, more abstract, to help clarify the issue, and in the hope of
> finding a form of words we can both agree on. If it didn't help, never
> mind. Please don't say obfuscation is my motive. That suggests I am
> debating in bad faith.

I never said anything about your motives -- only about your use of the term. The term was neither more precise nor more accurate nor more abstract.

> > Are you saying that instances of SmallInteger are stateless?
>
> Yes, of course.
>
>
> > Really? How does the SmallInteger class define addition?
>
> In the usual way. Adding two SmallIntegers makes a new SmallInteger. Thus:
>
> a := 2 + 4.
>
> This sends message #+ to the object 2 with argument 4. It returns a new
> object, 6, which is assigned to a.
>
> a := a + 1.
>
> This sends #+ to the object denoted by a, namely 6, with the argument 1.
> It returns a new object, 7, which is assigned to a.

Since instances of SmallInteger are stateless, am I to infer that 'a' is not an instance of SmallInteger? How does Smalltalk represent 6 differently from 7 without state?

> Here 'a' is a variable. 1, 2, 4, 6, and 7 are values.

I disagree. 'a' is a variable. '1', '2', '4', '6' and '7' are literals. Smalltalk constructs an implicit variable for each of the literals so that it can send them messages.

> None of the values
> are changed.

This is a facile statement. Values never change.

> The above does not make 6 equal to 7.

Why would it? You have not assigned anything to the implicit variable for the '6' literal.

> Assignment is always an
> operation on a variable, and messages are always sent to objects. We
> cannot assign to objects.

I agree that assignment is always an operation on an object variable, and messages are always sent to object variables. We cannot assign to object values. We can, however, assign to the instance variables of an object variable.

> > Do the same statements hold true for instances of Circle and
> > Ellipse? (Assuming either the setFoci or the setMajorAxis method
> > defined on Ellipse)?
>
> See my previous reply. Briefly, we would need to make the objects
> immutable.

How do we make the object instances immutable assuming we can use the setFoci or the setMajorAxis operation on Ellipse variables?

> > > I wonder if it would help to compare other languages, such as C++. In
> > > C++ 5 is an rvalue, meaning it does not have an address. It is not a
> > > variable.
> >
> > In C++, it is not an instance, either.
>
> True, but irrelevant.

How is it irrelevant to the discussion whether Smalltalk has instances that are values and not variables? If the item in question is neither an instance nor a variable, it serves little purpose to support your point.

> Whether or not we can send messages to something is
> (or should be) orthogonal to whether it is an rvalue.

It should be, but the Smalltalk standard requires a reference.

> In C++, class
> instances are sometimes rvalues and (nominally) have no addresses. (I say
> "nominally" because C++ is a bit confused about this.)

All class instances in C++ have an address referenced by the "this" pointer. In C++, the literal '5' represents neither a class instance nor a variable. In C++, "long", "int", "unsigned long", "unsigned int" are built-in types and are not classes. Received on Thu Oct 18 2001 - 02:00:42 CEST