Please, don't CC your messages to me privately. They get sorted into
different inboxes, and I end up answering personally when I should have
answered on the list and vice versa.

"Randal L. Schwartz" wrote:
> 
> >>>>> "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
> Joachim> words on anything :))
> 
> So you'll probably ignore this too.

No, this message doesn't ask me to take your word on anything, it's
interesting stuff for thought.

> 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).

OK. If you use the literal meaning of sub-routine, you're very right. I
attack the connotations of the Smalltalk terminology and don't notice
the misleading connotations of my own terminology. The only thing that I
have for an apology is that my terminology is the standard IT
terminology... which I agree is not very helpful if you want to address
people without a CS degree.

Personally, I think subroutines are black boxes that do something. Most
have a precondition (calling them is only allowed under specific
circumstances), and all have a postcondition (the effect that they
achieve). This is what makes subroutines powerful and useful beyond the
simple pack-some-instructions-together aspect.

I've seen the terminology "command" (for subroutines that change an
object's state) and "query" (for subroutines that inspect the object's
state without modifying it). I like the abstraction level of this
terminology, and its precision.

> 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".

But you have "above" and "below". The receiver is passive, the sender
active. The receiver is doing things at the command of the sender.

> 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!

The latter one is a serious candidate for problems. For example, if the
sender is in the middle of changing its state, the messages that hit it
may encounter an inconsistent state.
You can also get into ugly endless recursion problems, which are further
obscured by polymorphism.

For these reasons, I think that sending messages that may indirectly hit
the sender in a circle are a design error.

> 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.

That's standard issue in functional languages (an objectified message
send is called a "closure" there). It is not even related to OO as the
term is generally understood today.
This is also one thing that I don't like about typical Smalltalk
terminology: All concepts are united under the common roof of "the One
True Way of doing OO" even though experience has shown that they make
sense even in isolation.

> (Yes, for optimization, a message send is normally not fully
> objectified until something unordinary happens, but this is
> transparent.)

Agreed. Again, this is just like functional languages handle this issue.

> 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.

Yeah, polymorphism. This is the core concept of OO in the terminological
world outside Smalltalk.

> So, perhaps some core part of message send is like a subroutine call,

Agreed. That's my point.

> 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.

Agreed. It's a subroutine call plus polymorphism. Plus objectification
(but I don't think this is a very central concept in practice - unless
you actually need it, of course).

> Stop deluding yourself.

Oh, I could say this to everybody else as well. You're assuming you're
right and I'm not. I assume we're both right.

> 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.

[Rant elided.]

Please. Don't look so much down your nose. You don't have to; many of
your points are well taken.

Regards,
Joachim
-- 
Please don't send unsolicited ads.