Re: Clean Object Class Design -- Circle/Ellipse

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.

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

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

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

> You are agreeing with me that all instances are variables.

No, I am not. Please don't say I am agreeing when I am not.

> "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 have edited out huge amounts of your reply as it merely repeats points already claimed. Please try to minimise redundancy.

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

Here 'a' is a variable. 1, 2, 4, 6, and 7 are values. None of the values are changed. The above does not make 6 equal to 7. Assignment is always an operation on a variable, and messages are always sent to objects. We cannot assign to objects.

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

> > 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. Whether or not we can send messages to something is (or should be) orthogonal to whether it is an rvalue. In C++, class instances are sometimes rvalues and (nominally) have no addresses. (I say "nominally" because C++ is a bit confused about this.)

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,

      brangdon_at_cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed