"Pattern Hatching"

Dan Rozenfarb drozenfa at yahoo.com.ar
Thu Dec 5 14:45:05 UTC 2002


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 at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at 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 at lists.squeakfoundation.org
> Asunto: Re: "Pattern Hatching"
> 
> 
> "Daniel  Altman (Da Vinci)"
<Daniel.Altman at 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



More information about the Squeak-dev mailing list