>>>>> "Joachim" == Joachim Durchholz <joachim.durchholz at munich.netsurf.de> writes:

Joachim> As you may have noted, I'm not very good at taking anybody's words on
Joachim> anything :))

So you'll probably ignore this too.

A subroutine call brings *in* baggage that limits how a message send
might be used.  It's a limiting view.  In its very name "subroutine",
we are talking about a routine *below*.

A subroutine is a means to abstract a code step, to factor out common
code for reuse or readability.  But the code itself is not associated
with any data necessarily... except for recursion, it's all code that
theoretically could have been expanded in place in the original
caller (and for some subroutines, it is).

A message send has a much cleaner level of abstraction... this object
talks to that object, sending it some parameters, receiving some
parameters.  In "message send", I don't hear "above" and "below".
Heck, I don't even know or care how that object does it.  In fact, for
some cases, a message send could result in a broadcast of #changed:
messages, and then I end up getting or more messages sent back while
I'm still waiting for this one to return!

A "message send" is also an object, and can be captured for replay
later, or constructed so that the reciever issues it later, or for
meta-protocols like the debugger.  (Yes, for optimization, a message
send is normally not fully objectified until something unordinary
happens, but this is transparent.)

And, as already said, a "message send" is a late-binding operation,
but that's mostly to make it transparent about how the receiver
implements the object.

So, perhaps some core part of message send is like a subroutine call,
but I fear you lose all the more interesting parts of a message send
by the very bizarre mantra you are quoting of "a message send is
*just* a subroutine call".  It's not.  Stop deluding yourself.  If you
call it a subroutine call, you might as well go all the way to
Turing-equivalent, and then you lose all of why Smalltalk *is* unique.

-- 
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn at stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn at teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me