"Daniel  Altman (Da Vinci)" <Daniel.Altman at disco.com.ar> wrote:
	In OOP (at Univ. of Buenos Aires) we learn to call them this way:
	
	- variables --> internal collaborators
	- parameters --> external collaborators
	
Trouble is, it's wrong.
There are three things we can distinguish between.
(The classic "Informal Introduction to Algol 68" had a diagrammatic
 notation that made this all clear.)

1.  There is the NAME of a variable.
    This is the thing you type in.  It is made of letters.
 
2.  There is the VARIABLE itself.
    This is a box.  It is made of storage units in a computer's memory.

3.  There is the current VALUE of a variable.
    This is an abstract computational thingie, determined by interpreting
    the contents of the box in the context of the rules of the language,
    the structure of the program, and the contents of other boxes.

The collaborators are NOT the variables, they are the VALUES of the
variables.  Given
    Object subclass: #Point
        instanceVariableNames: 'x y'
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Graphics-Primitives'
and
    p := 27 at 2.4

Then
    'x'		is a variable name.
    p's x	is a variable
    27		is one of p's acquaintances.

I prefer the term "acquaintances" here because having been exposed to
Class-Responsibility-Collaborator cards, I think of a *class* having
collaborators which are *classes*.

The distinction between 'internal collaborators' and 'external collaborators'
is also a bad one.  If I have
    p := x @ y.
    q := y @ x.
then in what sense is x "internal" to p?  If I have
    "Complex >>"
    - other
	^Complex re: re - other re im: im - other im
    negated
	^Complex zero - self
then in what sense is a complex number "external" to *itself* when
passed to Complex>> -  by aComplex negated?  The distinction between
instance variables and method arguments is one of BINDING TIME only,
having nothing whatsoever to do with internal/external.

	My opinion is that it's more OO thinking an object as having
	collaborators (and interacting with them sending messages)
	rather than thinking those collaborators as variables, 

Anyone who confuses a collaborator (an object) with a variable (NOT
an object in Smalltalk) is about as seriously confused as someone
who confuses a person with a house just because a person lives in
a house.  Smalltalk objects have instance variables *SO THAT* they
can have acquaintances.

	[variables are] a concept
	that is usually associated with a value that you can directly
	manipulate.

You can "directly manipulate" something if and only if you can physically
grab it, move it around, and change it with your hands ('manes' in Latin).

Now, suppose I do this:
    (BorderedStringMorph contents: 'Boojum!') openInWorld.
then take the mouse, place it over the morph, Command-click,
select the red menu, choose "change font", and change the font.
The morph changes.  It _feels_ as if I made this change happen
with my hands.  That's "direct manipulation".  So by this definition,
a BorderedStringMorph is a variable.  That can't be right.

If I translate this into less metaphoric terms,
"a value that you can directly manipulate" appears to mean
"some kind of value for which your programming language provides
built in operations."

But then an array would not count as a variable in C.  Given
    typedef int ia10[10];
    ia10 x, y;
    ...
    x = y;
is illegal in C.  (Actually, the C standard would probably agree that
an array isn't a variable.  The C standard thinks it's an "object".)

What I find very serious here is that someone (almost certainly NOT
Daniel Altman, but perhaps someone who taught him) has tried to
LEGITIMISE the distinction between primitive values and objects that
we find in C++ and Java.  We find no such distinction in Eiffel or
Smalltalk.  In both Eiffel and Smalltalk, *everything* is an object.
ALL variables (notionally) hold references to objects.
(Eiffel has the idea of 'expanded' variables, which are born initialised
and cannot be reassigned.  It's basically a nicely thought out
efficiency hack which makes integers at one and the same time perfectly
good objects AND just bits that work exactly like C number.)

It has been conventional to call the boxes that hold references to objects
"variables" for as long as there have _been_ object-oriented languages.
(We've also had 'slots' (Lisp), 'features' (Eiffel), 'members' (C++),
 and a lot of other linguistic innovation whose chief purpose seems to
 have been to distinguish Us from Them.)