Re: Clean Object Class Design -- Circle/Ellipse

Bob Badour wrote:
>
> James A. Robertson wrote in message
> >In Smalltalk, variables are not declared as
> >being of a specific type - they are references to arbitrary objects.
>
> And the "arbitrary objects" are themselves variables. ie. They might change.

Hmm? They might change state - one can send messages that do that. One can always actually change the object via #become: or #changeClassToThatOf: as well, but those messages are

• primarily used by tools or distribution frameworks (proxy operations)

So tell me, in the course of normal Smalltalk operations, how does an object change in any sense other than state? And if you want to tell me that state changes are bad, then you simply have to assert that programming is bad.

>
> >In
> >Smalltalk, a variable doesn't have to reference any particular kind of
> >object.
>
> Neither does an object reference in C++.
>

But it has to refer to a specific kind of object. Tell me, why does this irrelevant issue bother you so much?  

> >> Perhaps, Richard would like to list his specific complaints that are
> >> pertinent to the discussion at hand? Or would you like to offer one or
> more?
> >>
> >> >> >2) Instances are not values.
> >> >> >
> >> >> >Since Smalltalk *has* instances that are values (the number
> >> >> >5 comes mind),
> >> >>
> >
> >Generally (In VisualWorks, most others are roughly similar), a variable
> >references an object.
>
> A named variable references an object variable.
>
> >In fact, it refs an object header, which in turn
> >refs the actual object.
>
> In fact, it refers to an object header variable, which in turn refers to the
> actual object variable.
>

sigh. No, you are wrong. Absolutely, or you are using words differently than everyone else. A variable in Smalltalk is nothing more than a declared name that refers to some object. The object header (and the object itself) are implementation details. Unless you are a VM implementor, how this is done is of no real concern. In fact, if you aren't a VM developer and you are concerned about it, then you are focusing on irrelevancies. Or as an instructor I know used to ask people with these sorts of questions, "why do you care?"

> >There are exceptions; one can have 'immediate'
> >objects, where the header actually holds the object (SmallInteger
> >objects, for instance).
>
> There are exceptions; one can have 'immediate' object variables, where the
> header variable actually holds both the header variable and the object
> variable.
>

You are using the term 'variable' very differently from the normal usage. One has no actual, direct control over the way objects are implemented in the system as a developer.  

> >For the developer, this doesn't actually matter.
>
> Except that Smalltalk makes insufficient distinction between value and
> variable preventing the developer from establishing proper, natural subtype
> relationships.
>

Sigh. Learn what the term 'variable' actually means, and maybe we can have a conversation. It does <not> refer to implementation artifacts.  

> >In fact, if you think
> >it matters, then you are paying way too much attention to detail.
>
> None of the irrelevant details you mentioned in your post matter. It only
> matters that Smalltalk makes insufficient distinction between values and
> variables, which I think you have amply demonstrated.

No, I think that you have amply demonstrated that you have no clear idea of what a variable is.

-- 
James A. Robertson
Product Manager (Smalltalk), Cincom
jarober_at_mail.com
<Talk Small and Carry a Big Class Library>