Re: Clean Object Class Design -- Circle/Ellipse

Bob Badour wrote:
>
> >Since Smalltalk *has* instances that are values (the number
> >5 comes mind)
>

This is trickier in Smalltalk. Why? because instances of classes are objects, and classes (and metaclasses) are also objects. The bottom line is that in Smalltalk, <everything> is an object.

> Hmmm... I have been looking for Smalltalk's definition of the term
> "instance". So far, all of the definitions seem to equate the term instance
> with the concept of variable:
>
> From http://www.wi2.uni-erlangen.de/sw/smalltalk/glossary.html
>
> instance: An object that is a single occurrence of a particular class. An
> instance exists in memory or external media in persistent form.

Variables in Smalltalk are nothing more than references to some object. That object can be anything

>
> From
> http://wuarchive.wustl.edu/languages/smalltalk/Smalltalk/faq/Definitions%20o
> f%20Terms.html
>
> [An instance] holds data and a pointer to the class which holds the code.
>
> From http://www.objs.com/x3h7/smalltalk.htm
>
> The instance of a class is created by sending a new message to the class
> which uniquely identifies the object instance and allocates space for its
> variable(s).
>
> and
>
> The state of a Smalltalk instance is represented by the values of its
> instance variables.
>
> and
>
> Smalltalk object instances are created with the "new" method. Each object
> instance is given a unique identifier called an object pointer or object
> reference.
>
> From http://www.fbk.eur.nl/FBK/VG1/JVH/OO/Smalltalk.htm
>
> all instances respond to the same set of messages and have the same number
> of named index variables
>
> I know what it means for a variable to have a specific value, but I do not
> know what it means for a value to have variables. Values, after all, do not
> change. The value, 5, for instance, never changes and exists independent of
> Smalltalk.
>
> One can represent a value in memory or in storage, but the value exists
> independent of the representation. Memory and storage are variable -- even
> hardwired ROMs are variable at some level.
>
> You aren't, by any chance, confusing "value" with "constant" are you? The
> ISO standard vocabulary for programming languages basically defines a
> constant as a variable constrained to hold a single unchanging value.
>
> In the sense of a variable constrained to a single unchanging value, an
> instance could be a constant but arguments surrounding setFoci and LSP would
> no longer apply. It would be an error either at compile time or at runtime
> to attempt to change the value of a constant using an update operation like
> setFoci.
 

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