Re: Clean Object Class Design -- Circle/Ellipse

"Dave Harris" <brangdon_at_cix.co.uk> wrote in message news:memo.20011007152312.52627A_at_brangdon.madasafish.com...
> bbadour_at_golden.net (Bob Badour) wrote (abridged):
> > > A /variable/ is a computational entity that stores a single
> > > reference (the /value/ of the variable) to an object.
> >
> > "reference to an object" implies that "object" is variable.
>
> No, it doesn't.

Actually, it does. The reference identifies some location that at one time contained the representation of a different value than the representation it now contains. Since it must have changed, it must be a variable.

> > Values are self-identifying and one cannot reference a value.
>
> This is confused - you are making it sound like a Smalltalk variable is a
> reference to a reference. It isn't, necessarily.

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. The value represented at that location or offset is itself a reference to a variable. However, I agree that programmers would simplify that to: In Smalltalk, all named variables are references to variables.

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.

> A variable is associated with two values: the value that it is, and the
> value that it has. The value that it is is its identity, what in concrete
> terms we might call its address.

Addressed based identity proved impractical for database management. (See the network and hierarchic data models.) The relational model specifies a logical identity independent of address or location.

> The value that it has is the contents of
> that address. We can store a number like 5 or we can store the
> address/identity of another variable.

In Smalltalk, all named variables store a reference to the address of a variable or a reference to nil.

> Thus saying a thing is referred to
> by a variable does not tell us whether it is a value or a variable.

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.

> Or
> rather, it will always be a value but that value may or may not be the
> identity of a variable.

In Smalltalk, all named variables store the address of a variable or a reference to nil.

> Incidently, I harp on about variables having two values because I think it
> helps clarify what is going on. Both values are immutable, but the
> attachment between them can change. Thus in an assignment like:
> a := 5.
>
> the variable denoted by 'a' does not change - it keeps its identity, its
> address stays the same. Likewise 5 doesn't change either. What has changed
> is that a is now attached to 5. The /attachment/ changes.

In Smalltalk, after the assignment, the variable denoted by 'a' contains a reference to a variable that stores a representation of the number 5. From the example given, we cannot tell what value the variable denoted by 'a' contained prior to the assignment, but we do know it contained either a reference to a variable or a reference to nil.

You are agreeing with me that all instances are variables. We do not need to confuse the issue by inventing new vocabulary like "attachment".

> > One can reference storage or memory that contains some representation
> > of a value, but storage and memory are variable.
>
> When we are doing that, the value attached to one variable is the identity
> of another variable.

Again, you are agreeing that all instances are variables.

> This identity is another value, immutable just like
> the value 5.

I agree.

> Storing 5 into a variable and storing an address into a
> variable are much the same thing.

I agree.

> In both cases we are changing the
> attachment between a variable and a value.

We do not need to confuse the issue by introducing new vocabulary; both programmers and database managers understand what "storing" means.

> Think of it this way. If variables can only refer to other variables,
> never values, how do we get out of the infinite recursion?

I never claimed that variables can only refer to other variables. In Smalltalk, all named variables store pointers to variables. The variables pointed at can contain indexed arrays of bytes, indexed arrays of pointers to variables, or further named variables that contain pointers to variables.

> Well, maybe
> there are ways, but in practice it doesn't work like that. Instead, every
> variable is a reference to an immutable value.

The address is an immutable value that identifies a variable.

You are agreeing with me that all instances are variables.

> Some of those values are
> identities of variables and so have mutable attachments of their own.

Again, you are agreeing that all instances are variables.

> (The words "identity" and "attachment" are more abstract than "address"
> and "store". There are many ways to implement the mapping between a
> variables two values.)

Identity is a concept one can logically describe many ways and that equates to the more abstract (or general) meaning of address. In the relational model, one addresses an object value using a relation, a column name and a specific value of some candidate key. Candidate keys provide logical identity independent of physical storage location.

Attach is an unnecessary synonym for store.

> Here's an example:
> 5 max: 6.
>
> This will end up in a method declared like:
>
> max: aNumber
>
> Now, aNumber is a variable that will be attached to the value 6.

Actually, aNumber is a named variable that stores a reference to a variable that stores a representation of the value 6.

> It will
> be attached to different values in other calls.

It might point to a different variable or it might point to the same variable with a different value.

> Clearly aNumber is a
> variable. However, this does not mean it is attached to a variable.

"Attach" is newly invented vocabulary that only confuses the issues. According to the Smalltalk specification, aNumber is a named variable that contains a pointer to a variable. In this sense, it is always "attached" to a variable even when you choose to ignore the "attachment" for your argument's sake.

> > 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.
>
> Not true. Inside the method we use variables to refer to the argument
> objects, but the objects themselves can be values.

Sorry, but that is not what the Smalltalk specification says. Inside the method, you use named variables that contain pointers to variables.

> In the method call we
> see naked values.

I disagree.

> 5 is not reference to an address.
>
> I think I see what you are saying, though. I believe early Fortran worked
> like that. Smalltalk doesn't, not according to its definition nor in how
> it is implemented. At machine code level, the object 5 will likely be
> stored directly in a register. It will not be represented as an address.

In the case you identified as likely, a representation of the object value 5 is stored in an instance of CPU register. The instance is still a variable -- in this case a register chosen by the compiler during optimization.

> > > (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?
>
> I don't follow the question. My discussion of attachments may help.

It did not. "Attachment" was only an artifice used to obfuscate the issues.

> Alternatively, are you supposing that because some objects have state, all
> objects have state? An object which does not have state cannot be changed,
> by definition.

All supertypes of a stateless object have no state, which obviates any LSP issues.

> > > 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
>
> This is confused again.

I disagree; it is an accurate description of the situation based on a proper understanding of value, variable and instance.

> An instance of SmallInteger does not /contain/ a
> representation of 5, it /is/ a representation of 5.

Your statement is false on the face of it. In the classic LSP argument against making Circle a subtype of Ellipse, the apologist claims that setFoci would change the state of an instance of Circle in violation of an invariant. Instances have potentially mutable state or no state at all. Are you saying that instances of SmallInteger are stateless?

> Instances of SmallInteger do not have addresses, they cannot be assigned
> to, they do not have attachments. They have no identity other than their
> value, but that value can be referred to, or assigned to, variables.

Really? How does the SmallInteger class define addition? Do the same statements hold true for instances of Circle and Ellipse? (Assuming either the setFoci or the setMajorAxis method defined on Ellipse)?

> > 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? Of course, the Smalltalk standard
> > requires all implementations to operate only on variables.
>
> Not true. The above #max: example shows an operation being applied to a
> value, not a variable. It was not an update operation, of course.
>
> I am going to stop commenting now, because what follows is just repeating
> points already made.
>
> 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.

> In Smalltalk it is the same.
>
> 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
> http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Received on Mon Oct 08 2001 - 12:04:45 CEST