Hi Richard and all,
Daniel Altman wrote:
That's a very unfair conclusion...I was taught that
in OOP we
only have objects and messages, nothing else.
And Richard O'Keefe replied
Whoever told you that was lying.
I don't think that Truth has anything to do here. Besides, it is possible that we just think different. I already tried to answer you some of these issues in a previous email on Friday 11/29/2002 (see http://groups.yahoo.com/group/squeak/message/52995). I'll try to further elaborate here:
1. I don't believe there is such a thing as *the* way to explain what objects are about (or any other subject whatsoever). 2. Every sentence, and every explanation, is a simplification. Any abstraction is a simplification as well and, as such, has loss of information. You can thus regard them as mere lies. Quite to the contrary, I believe they are necessary to explain things. 3. Related to 2, I believe in a pedagogical approach in which we give a general notion/rule first and then move forward to find its exceptions and implementation details. Students then understand why a feature is needed or an exception is found. For me, variables are just an implementation issue (more on this later) and as such, are not an essential part for the understanding of objects. 4. Quoting the above mentioned email "... we teach that in an Object Environment we only have objects collaborating through message sending, essentially nothing else" 'Essentially nothing else' means that there are other things not covered in those words. Besides variables, for example, in all known object environments there are also things like primitives. I wouldn't mention them when teaching what objects are about in a brief, understandable and even easy to memorize sentence. Nor did Alan Kay when he described what Smalltalk is about (see http://www.ira.uka.de/~marcus/_The_Early_History_of_SmallTalk_.html) 5. The quote referred to in 4 is obviously incomplete, in that it is not even defining what Objects and Messages are. I could perfectly define objects as entities with memory (as Alan Kay did) or as having variables. In fact, during our course, we do advance on those definitions, so that our "lie" is soon discovered. 6. Several different abstraction levels are being mixed up in this discussion. Variables are just a way to represent a knowledge relation between objects. According to my opinion they should be taught as an implementation issue (though a very important and common one), since there are other ways for an object to be related with another one. On the other hand, Objects and Messages are much more important than variables, and I give them a status and an abstraction level different and superior than that of variables
Instance variables are not objects
Unfortunately, in my opinion.
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.
I already explained that we agree on this.
It so happens that global variables, variables in
pool
dictionaries, and class variables *are* objects in
Smalltalk.
That's right. And they can also be seen as a special knowledge relation, since they allow an object to collaborate with a "well known" one. That is not to say that the latter is well known per se. It is the existence of such global variable what lets the relation exists.
This is truly bizarre. It's beyond satire. We need
a new
Aristophanes or a new Orwell to do justice to this.
I don't think this adds much to the ongoing discussion.
Whatever you *call* them, Smalltalk just plain *has*
variables.
During our course, we don't say the opposite, but introduce the term later.
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.
I might be wrong here, but I interpret Daniel words (Dany, correct me if I got it wrong) this way: An object P doesn't know C in an absolute fashion (e.g. its identity) but does it through a variable. In fact, P is perfectly comfortable with any object referred to by the name (and indirectly by the variable) as long as C satisfies certain conditions (implicit in Smalltalk) such as accepting a certain set of message selectors, being of some type, etc. As you expressed in some other place, the object behind the name may change, but that doesn't modify the fact that there should always be some object (including nil) there. There is always a collaborator, and that is what P knows, not who is it.
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.
As explained in my previous email, we do.
Regards, Dan Rozenfarb
-----Mensaje original----- De: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]
En
nombre de Richard A. O'Keefe Enviado el: Lunes, 02 de Diciembre de 2002 10:15
p.m.
Para: squeak-dev@lists.squeakfoundation.org Asunto: Re: "Pattern Hatching"
"Daniel Altman (Da Vinci)"
Daniel.Altman@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.
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
squeak-dev@lists.squeakfoundation.org