"Daniel Altman (Da Vinci)" <Daniel.Altman(a)disco.com.ar> wrote:
>The collaborators are NOT the variables, they are the VALUES of the
variables.
Of course! You won't expect an object to send a message to a
computer memory area! ;-P
"Objects" are at one level of abstraction,
"computer memory areas" are at another (lower) level.
Maybe I wasn't clear enough, as you said in another post, we
usually don't say exactly (formally) what we mean, which is
impossible because spoken language is not formal.
I'm sorry, I don't buy this. The point that I was making is that
programmers (and beginning programmers) are writing and talking to each
other (and above all to themselves) about technological things.
"Humane" concepts (like colour names) have good centres and bad edges.
A good reference on this is "Women, Fire, and Dangerous Things."
"Technical" concepts (like programming language terms) have good edges
and bad centres. One triangle is as good an example of the concept
"triangle" as any other, but add just one more point and it's no longer
a triangle, or sort of like a triangle, or triangleish, it's just plain
not a triangle. The difference doesn't lie so much in the person doing
the talking nor even in the subject matter, but in the nature of the
"thing" that "interprets" our communication.
When we talk to people about humane concepts, what we say will be interpreted
by an extremely bright ape with strong preconceptions based on experience of
(as it happens, a vanishingly minute portion of) the physical world. When we
draw diagrams for machines, they will be "interpreted" by the laws of nature
embodied in those machines in the dumbest and most literal way. Above all,
when we "communicate" with a computer, it will do what we say, not what we
mean.
What about if we draw diagrams to be interpreted by a human machinist
who will make the machine? If the machinist is really good, s/he may
very well correct errors in our drawings. If the machinist is less
skilled, s/he is likely to do literally what we say.
I have talked with students who were deeply confused about the difference
between a semaphore and an array of semaphores. Why? Because they had
been taught about the System V semaphore interface by someone who called
the thing that the documentation calls a "semaphore set" a "semaphore".
And they believed him. So they thought that semaphores could be members
of semaphores.
I have tried to help C students who found it hard to break themselves
of the habit of putting semicolons at the end of directives, as in
#define NumElements 10;
because they had been taught by someone who called directives
"statements" and they knew that "statements" end with semicolons.
If you teach other people using sloppy language that muddles up different
things with the same word, they will internalise what you tell them, they
will learn to call those different things by the same name, and they will
then have a hard time trying to understand why the "ONE" thing you are
talking about has such contradictory properties.
As for whether language can be formal, you'd have to talk to the
people who know about Loglan (now called Lojban, I believe, but I'm
probably mistaken) and the experts in Shastric Sanskrit, which I am
told was deliberately devised to be a precise natural language.
I do know that it is possible to be more formal and more careful than
we normally are, and that when I talk to myself in sloppy terms about
what I'm trying to do in a program I end up believing myself and making
mistakes I could have avoided if I'd been more careful in my speech.
So, please don't take things too literally.
As a software engineer (which I like to think I once was),
it was my job to try to understand things clearly.
Hand-wavy "you know what I mean" stuff was invariably
stuff where we DIDN'T know what was meant and led to trouble.
As a university lecturer, it is my job to explain things to
my students as clearly as I can. "Be generous in what you accept
and strict in what you generate" is a good motto for lecturers.
We call "collaborators" to the objects, not to their memory
storage.
"We call X to Y" means "We say 'X' to Y in a voice that is intended
to carry some distance", perhaps because Y is in another room or
across the quad. You can accuse those nasty objects of being
collaborators at the top of your voice, but they won't hear you. (:-)
Nobody ever said that you called the storage holding an object
a collaborator; what you wrote was that you called a VARIABLE
(represented by storage in another object entirely) a collaborator.
So we have
Language level ISA level
object P region of storage S
variable v of P region of storage T included in S
object C region of storage U
reference r to C bit pattern b
object P contains S includes
instance variable v T which holds
whose value is r bit pattern b which is interpreted as
which refers to C address of U
The issue is not whether C or U is the collaborator
(both are, in some sense)
but whether C or v is the collaborator
(and only C is, not v).
More important than this is that an object really don't "know"
its collaborators, it only knows that behind a certain "role"
(or "variable name", or "collaborator name", or simply "name")
there is someone that is expected to complain to some protocol.
Here you are pushing hard on the semantics of 'know'.
I would say that the object P *does* "know" its collaborator C,
and that the instance variable v is the means by which it does this.
But the thing of importance here is NOT the variable *name*
but the variable itself. Change the name consistently, and nothing
of importance changes. Nor is the "collaborator name" involved;
objects in Smalltalk don't *have* names. (I am not denying that they
have identities or can be referred to; what I am denying is that
*objects* have names like 'Association' or 'key'. 'Association' is
the name of a global variable, and the relationship between the name
and the value of the variable is *mutable*. Object identities are not
mutable.)
> The distinction between 'internal collaborators' and 'external
collaborators' is also a bad one.
> The distinction between instance variables and method arguments is one of
BINDING TIME only, having nothing whatsoever to do with internal/external
The concept is that an external collaborator is one that the
object "knows" only in the context of a certain collaboration.
An internal collaborator is one "known" along the entire
lifetime of the object.
Here is more confusion.
An instance variable is a facet of an object which
(a) can contain a reference to another object and
(b) can change.
The *variable* exists as long as the object does.
The *value* of the object can change at any time.
A collaborator is an object, not a variable.
Just because an instance variable v holds a reference to object C
at some time does *NOT* mean that the collaborator C is '"known"
along the entire lifetime of the object'. As soon as v is set to
some other value, C is no longer known.
With the exception of a variable which is never set,
virtually *all* instance variables in Smalltalk *do* change
(they are born 'nil' and are set some time later), so
by the criterion '"known" along the __entire__ lifetime of the
object' Smalltalk doesn't have any internal collaborators.
This does not mean that some other OO language might not have
read-only associations between objects.
As I pointed out previously, just because a reference to object C
has been passed as a method parameter in some method call to object
P, that does NOT mean that C 'is one that the object [P] "knows"
only in the context of a certain collaboration'. It is, for example,
not unknown for an object to pass ITSELF to itself. It is certainly
EXTREMELY common for the value of an instance variable (therefore
an 'internal collaborator') to be passed as a parameter in a method
call to self, thereby making the object referred to an internal
collaborator AND an external collaborator at the same time.
I do not find the internal collaborator/external collaborator distinction
useful for anything in my own programming or for understanding anything
in the patterns literature that I have read so far. I have now explained
twice that I don't even find the presentation so far coherent.
What is beyond dispute is that the distinction as so far explained
is not at all the same as the distinction between method parameters
and instance variables.
An instance variable has the same lifetime as the instance it is
a part of. It is a variable, that is, the association between
the variable and its current value may be changed.
A method parameter has the same lifetime as the context set up by
the method call where the parameter was passed, or possibly somewhat
less if the compiler is clever enough. It is not a variable, that
is, the association between the variable and its current value may
not be changed.
That's a very unfair conclusion...I was taught that in OOP we
only have objects and messages, nothing else.
Whoever told you that was lying.
Instance variables are not objects and they are not messages.
They are PARTS of objects.
Method parameters are not objects and they are not messages.
They are PARTS of messages.
It so happens that global variables, variables in pool dictionaries,
and class variables *are* objects in Smalltalk. (More precisely,
for each such variable there is an Association object, and the
variable _name_ is the key of the object and the variable _itself_
is the 'value' instance variable of the Association.) However, you
could have an implementation of ANSI Smalltalk in which these things
weren't objects either.
It so happens that in Smalltalk method activations are defined to
produce Context objects; in most other OO languages these "activation
records" are NOT objects, yet they are important for understanding how
method calls work. For example, they are not objects in CLOS or Eiffel.
One of the reasons we don't use the word "variable" is that it
sounds too imperative, thus making more difficult to switch our
minds to OO.
This is truly bizarre. It's beyond satire. We need a new Aristophanes
or a new Orwell to do justice to this.
Whatever you *call* them, Smalltalk just plain *has* variables.
My main claim to fame is writing a book about Prolog. Such consulting
income as I've had over the last few years has mostly been in connection
with a language called Erlang. I'm an admirer of Mercury, Clean, and
Haskell. These languages are declarative languages. They don't have
any analogue of the assignment statement. From a logic programming/
functional programming perspective, Smalltalk and C are hard to tell
apart without a microscope. And yet logic programmers and functional
programmers feel no shame or awkwardness using the name 'variable'
for the named things that are bound to values at run time, things whose
closest analogues in Smalltalk are method parameters (which cannot be
changed). Nor do we find that continuing to use a well understood
computing term has any significant effect on making it difficult to
switch people's thinking.
Smalltalk has variables and assignment statements.
A variable is precisely the thing that an assignment statement changes.
To me, the assignment statement is the essence of imperative programming,
and Smalltalk is an imperative OO language.
A variable is not a collaborator
any more than an address is a house.
