You folks are kidding about all this, aren't you?

A message is not a subroutine. E.G.

billy := 5. billy printString. billy := 'mary'. billy printString.

How clever would a subroutine named printString have to be in order to order to come up with different answers for each different type of object in the system? A mighty big case statement, pardner. And we could use recursion too for arrays and the such !!! Oh, and of course you would need to somehow identify what type of 'object' that you are passing to your subroutine. Using a language such as C, all you would have to do is create a different structure for each object in the system for identification purposes. Or even better, you could use constants or enums to define the object type being passed to your printString subroutine. Of course, you would only need to do this everytime you decide to use a messaging construct.

Maybe you can simulate some things that the messaging paradigm describes with subroutines, Lord knows that they butchered C++ trying to do that. But dynamic dispatching and data encapsulation is what makes Smalltalk interesting to me.

Give me a break,

Jim Benson

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