🚀 go-pugleaf

pcg@aber.ac.uk (Piercarlo Grandi) wrote:
>The goal of the pragraph above was to make it obvious that
>the 'r m: a' notation is just syntactic sugaring for 'm(r,a)', where 'r'
>is just the one argument on which dynamic overload resolution is done.
>[...]
>There is nothing magic in overload resolution, whether static or dynamic
>-- it does garner the same benefit, extended reuse, and, possibly,
>genericity, which also obtains further reusability.
>It is something that many languages have, even dynamically, without
>being OO. I see no point in confusing innocent people (like you) with
>calling 'message sending' the special case in which overloading is
>resolved at runtime.

You didn't mention this last fact about dynamic resolution before. 
Without it, the statement says as much--or as little--as  "m(r,a) is just
a syntactic sugar for (m r a)", or the other way around.  Indeed what
matters is how any of these constructs is used to determine a specific
procedure to apply to the arguments.  By a "specific procedure" I mean a
C function, or C++ member function (not pure), or CLOS generic function's
method, or Smalltalk method--i.e. a chunk of code doing "the real job"
(therefore, generic functions themselves are not "specific procedures" in
this terminology).

Just three of a large number of possibilities are: (1) the procedure is
determined at compile-time based on its name (what I called a "plain"
function call earlier); (2) a set of candidate procedures (as small as
possible) is determined at compile-time based on the types of variables
(or other procedures' return value types) used as parameters, and the
resolution is finalized at runtime based on the values the variables are
actually bound to; (3) the procedure is looked up only at runtime, based
on the values used as its arguments.

What relation does each of these strategies have to OO programming--this
is an interesting question.  I won't go into discussion of how innocent
or confused everybody at comp.lang.smalltalk is--there's a lot of people
around here, but what you are probably confusing--at least in your
arguments, my apologies if not in your mind--is a model and its
implementation:

When we build a model of a system using any of the now abundant
object-oriented approaches, we build it of objects "talking", i.e. 
sending messages, to each other--because it looks like a Right Thing (tm).
Then we go into the real world and start implementing it.  We can use any
language to do that.  But in some languages it appears easier than in
others, just because they happen to have neat costructs that come in handy
when we want to turn talking objects of our model into the code of our
implementation.

Note that, strictly speaking, OO as applied to modeling and implementation
language is *not* the same.  In the first case, it means we use "talking
objects" to build a model, believing it is a Right Thing.  In the second,
it means that the language provides constructs OO models are easily mapped
into.  One does not necessarily imply the other, though it is nice when
they come together.  (Speaking of language constructs I don't mean its
syntax, or terms used by that particular language's adepts for its
specific strategy of procedure lookup.)

All the above verbiage was to say that message passing is, first of all,
OO modeling term.  Smalltalk procedure lookup strategy (3) simulates it
closer then the other two, this is why "message passing" has migrated into
Smalltalk terminology as well.  This is, at least, what I mean by "message
passing in Smalltalk", and I wholeheartedly agree with you that it is the
same good old procedure invocation, just the lookup strategy is different.


--Vassili