Re: Clean Object Class Design -- Circle/Ellipse

Bob Badour wrote:

> brangdon_at_cix.co.uk (Dave Harris) wrote in message news:<memo.20011008212902.61375B_at_brangdon.madasafish.com>...

<snip>

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

I'll put this the way that the person who mentored me in Smalltalk did when presented with these sorts of questions:

'Why do you care?'

How an object is stored in memory is an utterly irrelevant implementation detail. It has <nothing> to do with how objects behave, with the exception of identity checks. And it turns out that your assertion is incorrect, although it doesn't matter. Every Smalltalk implementation I know of actually stores SmallInteger objects directly in the object header, rather than offset somewhere in memory. Such objects are called immediate. When integers get too big to fit in 29 bits (there are housekeeping bits, including the one to indicate that the object is immediate), it is seamlessly replaced with a LargePositive or LargeNegative.

But none of this actually matters to the developer; it's an optimization - just like the movement of many math operations to the VM (primitives) are optimizations.

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

Again, why do you care? In development terms, it doesn't matter - that's all implementation detaiul stuff that does not impact the developer.  

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

In this case, no - it will actually contain the actual object, because it's an optimization. Not that it matters in real terms...  

>
>>>"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?
>
>

They are stateless in that SmallInteger objects have no instance variables - thus no 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.
>

Nope. But again, it's not as if it matters.  

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

No, it doesn't, and implementations don't work that way. Whether we can or cannot send messages or update instance variables doesn't have anything to do with the implementation details. Making an object effectively immutable can be done at the image level with ease.

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

Which is a problem... Received on Thu Oct 18 2001 - 15:59:13 CEST