Variables, Names and Objects (was: Pattern Hatching and also: A big teacher wish)

Dan Rozenfarb drozenfa at yahoo.com.ar
Fri Nov 29 17:40:37 UTC 2002


Hi,


> What I find very serious here is that someone
(almost certainly NOT
> Daniel Altman, but perhaps someone who taught him)

As one of those who taught Daniel I thought I should
jump into


>  has tried to LEGITIMISE the distinction between
primitive values and objects
>  that we find in C++ and Java. 

I believe you are making a whole lot of assumptions of
just a couple of names Daniel mentioned, though I
recognize that the way he put them can be misleading. 
We never legitimized such a distinction.


> > "Daniel Altman (Da Vinci)" 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.

I don't see why.  I explain them below


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

I know this and agree.


> The collaborators are NOT the variables, they are
the VALUES of the variables.

Correct, who said the opposite?
You just inferred (over inferred?) it from a couple of
lines.


> The distinction between 'internal collaborators' and
'external collaborators'
> is also a bad one.

I don't agree, but let me elaborate a bit further.
In our course, our primary focus is Objects, Smalltalk
is just an implementation of Objects (though nothing
less) as is Self.
In that sense we teach that in an Object Environment
we only have objects collaborating through message
sending, essentially nothing else.  Thus objects send
messages to others to collaborate, and that is why we
call those 'Collaborators', not the NAMES, not the
VARIABLES, but the VALUES, as you call them.
But for an object to collaborate with any other, he
must know it first.
>From a conceptual point of view, the message sender
only knows the receiver by name [1], and that name
could be global or local.  Local being: instance
variables, temporary, parameters, etc.  And globals:
everything in the Smalltalk dictionary, or in globals
(or lobby, don't recall exactly) in Self.
Now, from an implementation point of view Smalltalk
and many others use variables to bind those names and
the collaborators.  Unfortunately, variables in
Smalltalk are not objects.
The distinction between external and internal is for
expressing the relationship between an object and the
collaborator "behind" the name.
In the 'Internal collaborator' case we are not saying
that the object owns the collaborator (who may even
change during the object lifetime), but that has an
acquaintance to which he closely collaborates with. 
So closely as to don't need for others to send it to
him as a parameter every time.
On the other hand, an 'External collaborator' is not
an acquaintance.  Although the object can send
messages to it [2], is external in the sense that it
was needed to receive it as a parameter in a message
in order to do so.
According to my opinion, though reasonable people may
disagree, this notation is very object oriented, not
misleading and very understandable by students [3].
Also, as you point out in another email:
> It is in general *impossible* for a name in a
program to express the whole truth.


>  If I have
> p := x @ y.
> q := y @ x.
> then in what sense is x "internal" to p?

Here, you are confusing x ownership, which of course
the point don't really have, with a name we use
regarding the fact that a point will "always" have an
internal name that will point to a collaborator at any
time.


> The distinction between instance variables and
method arguments is one of BINDING TIME only,
> having nothing whatsoever to do with
internal/external.

No.  From a semantic and modeling point of view, it is
not the same to make an object have an instance
variable than to receive a parameter.  The nature of
knowledge and relation that exists between the object
and one or the other is different.


> My opinion is that it's more OO thinking an object
as having
> collaborators (and interacting with them sending
messages)

We agree.
Now that you mention OO thinking, let me point out
that I don’t like the term VALUE.  Although you
mentioned it in the context of Algol, I believe it is
misleading.  It should just be OBJECT.  VALUE has old,
and unwanted connotations.
There is another meaning for value, however, that I
regard as important but has to do with a different and
higher abstraction level than the one we are talking
about here (see http://domainlanguage.com/book.html)


> rather than thinking those collaborators as
variables, 

We never did so


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

According to my opinion, that’s wrong.  A class
doesn’t collaborate with other classes, rather their
instances are the ones who do.  That way, you can
replace a collaborator with some other which is
instance of ANY class, as long as it can respond to a
certain common protocol.  You seem to be limiting
collaborator to objects belonging to a class
hierarchy, just as Eiffel does.
Of course, I know that classes are objects as well, so
that what I’m saying may sound circular, but I hope
you’ll understand what I mean.


Best regards,
Dan Rozenfarb

[1] You can also add a "contract" here, and some other
things, but I am simplifying here
[2] After all, he has given it a NAME in the method
text, and a VARIABLE will be created ad hoc to bind
the NAME to the VALUE in the activation
[3] They tend to use an informal design heuristic,
which matches internal with frequent and external with
less frequent, for helping them deciding whether to
declare an instance variable or a parameter


----------

"Daniel Altman (Da Vinci)" <Daniel.Altman at d...
</group/squeak/post?protectID=132166234009056153033222001056124253000098015241077171188150166091061076020227>>
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...
</group/squeak/post?protectID=196084101081035071>

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


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



More information about the Squeak-dev mailing list