🚀 go-pugleaf

>> pcg>  [a bunch of stuff about terminaology 'message sending' vs.
           'procedure calling']

>Michael> Sending a message does, indeed, invoke a method.

>In the current Smalltalk terminology, the method is invoked as a
>consequence of 'sending a message'. But please note that I was making
>the point that a _different terminology_, less confusingly dissimilar
>from that used for other languages, should be used, for what happens in
>Smalltalk is exactly the same as what happens in other languages, and
>using a different terminology makes some people (and we have seen the
>very phenonemon in this thread) mistakenly believe that there is also
>different semantics behind it.

It is *not* the same thing.  Subroutine calls and gotos are both
'transfers of control' but thinking about them the same is a *big* mistake.
Likewise for 'message sending' vs. 'procedure calling'.  The terminology
helps the programmer think (in the context of the sending code)
what he wants done rather than how it is to be done.

As an aside, in my dialect of Smalltalk (ParcPlace VisualWorks), there 
is actually a little known method for doing 'procedural calls', i.e.
bypassing the message dispatching mechanism.  It is *extremely* rarely used.
It is also, in terms of makeing foreign code safe to execute, The most open
point of attack, since it can be used to penetrate encapsulation.
(For anyone who cares, it is <primitive 523>, 
in CompiledMethod>>valueWithReceiver:arguments:
)

>In more conventional languages, one usually speaks of 'calling a
>procedure' instead of 'sending a message', and of procedure interface
>instead of selector and procedure body instead of method. Often, and
>this was I used it in the above paragraph, 'method' is used to denote a
>procedure (not just its body) that belongs to a class, to emphasize the
>fact it is not standalone; I personally like better 'method' than
>'member function', in effect.

In more conventional languages, (like C) the equivalent of sending a message
does not exist.  In C++, you could say 'calling a virtual member function',
(as if that were clearer), but you first would have to verify that that 
particular function was actually declared as virtual.  I'm not clear on Java
terminology, but 'message sending' has been part of OO terminology for over
20 years.

Methods are units of Smalltalk code (as are blocks).  In conventional languages
procedures, subroutines, and functions are the units of code. The differences
between procedures, subroutines, functions, vary from language to language.
Method in Smalltalk are analogous to procedure bodies.  Methods may "belong"
to zero, one, or many classes, or to other objects.  It is usually the case that
they "belong" to a single class, but it doesn't have to be.  Doits are methods
that do not belong to any class (usually called unbound methods).

>Michael> But when you write the code that sends the message, you don't
>Michael> know *which* method it will invoke.

>So what? If you use the Smalltalk terminology (method == procedure
>block), this is nothing special: many languages associate multiple
>implementation with one name. 

The important point is whether resolution is done at compile time,
or run time.  Smalltalk always defers resolution to run time.

>I prefer to speak of 'method' as in "the
>addTo: method' (that is procedure, whereas that is the selector in
>Smalltalk's original lingo), and then you know which method you have
>invoked, 'addTo:', just not which implementation (note that a single
>procedure might have multiple implementations that are semantically
>equivalent, but that are pragmatically different, unfortunatley few
>languages support the idea).

That would be different than Smalltalk's terminology.
There may be several addTo: methods (or procedure bodies).
You dont know which code unit will be executed.  You know what it it supposed
to do (its name, or selector), but you dont know how (the method, in the Smalltalk
sense).  It is unclear when you are talking about procedures exactly what you
are referring to.  The Smalltalk terminology is exact and unambiguous.

>Michael> That's polymorphism.

>I am already on record as saying that "polymorphism" is such a flexibly
>defined word that it had better be forgotten. Yours is just one of a
>million definitions.

Saying that a word is too flexibly defined just means that you haven't
found a definition worth adhereing to.  Smalltalk has.  Good luck with your search.

-- 
mklein@alumni.caltech.edu