Enough of this wordplay!
Joachim's argument is rooted upon the proposition that Smalltalk programmers should use a mainstream terminology, which he insists prefers terms such as "function," and "method," to terms such as "messages," or "messaging," and since he feels that "message sends are just the same as functions." He provides no substantive reason why the term "function call" is better than the term "message send," apart from his insistance that the latter is disused in favor of the former.
I have been unable to confirm his assertion. A review of object-oriented literature in my library suggests that opposite to be true: that "messaging" or "message send" is a mainstream (perhaps the) usage for the concept, and that the awkward phrase "member function call" isn't an overwhelmingly favored usage at all. Let us consider James Gosling's view, which casts a striking contrast to Joachim's:
"If an object wants another object to do some work on its behalf, then in the parlance of object-oriented programming, the first object sends a message to the second object."
James Gosling & Henry McGilton, The Java Language Environment, A White Paper, http://www.javasoft.com/docs/white/langenv/ (Section 3.2: Methods and Messaging).
Q.E.D.
Certainly it is true that some formal language specifications do use terms other than "message send," or "message passing" to define particular syntactic constructs in particular languagea, such as C++ which uses the term "member function calls" (and which is expressly distinguished from mere "function calls"). On the other hand, as I passed through a small sample of books at hand in my library talking about actually programming or designing using C++, each reverted to the more traditional messaging terminology.
Now, in the sense of full disclosure, I have done far more practicing of law than hacking since I left graduate school and since I sold my software publishing businesses. Accordingly, my libraries haven't been kept entirely up to date. It may be that the more traditional uses have ultimately been usurped and wholly preempted by the term "member function call."
However, all indications appear to be to the contrary.
agree@carltonfields.com wrote:
Joachim's argument is rooted upon the proposition that Smalltalk programmers should use a mainstream terminology, which he insists prefers terms such as "function," and "method,"
Not even "method". But that is an aside point; the substance of my argument is presented correctly.
to terms such as "messages," or "messaging," and since he feels that "message sends are just the same as functions."
The latter is a bit overstated (and has a terminological mix-up that I hope I never wrote). I admit I said something like that in the heat of the debate, but what I really mean is that message sends and subroutine calls have a lot in common and the Smalltalk folklore doesn't acknowledge that.
He provides no substantive reason why the term "function call" is better than the term "message send," apart from his insistance that the latter is disused in favor of the former.
Correct. I don't like the construction "provides no substantive reason... apart from" though; it's rather negative rhetoric.
I have been unable to confirm his assertion. A review of object-oriented literature in my library suggests that opposite to be true: that "messaging" or "message send" is a mainstream (perhaps the) usage for the concept, and that the awkward phrase "member function call" isn't an overwhelmingly favored usage at all.
Well, the books on my shelf have a different slant. It's probably a better idea to look at the shelves of a library.
Let us consider James Gosling's view, which casts a striking contrast to Joachim's:
"If an object wants another object to do some work on its behalf, then in the parlance of object-oriented programming, the first object sends a message to the second object."
Well, that's James's view of things. I don't accept authorities just on the basis of words. I have seen lots of authorities presenting their personal view of the world as unshakeable truth (and it's all too human I guess; I don't hold it against them).
Certainly it is true that some formal language specifications do use terms other than "message send," or "message passing" to define particular syntactic constructs in particular languagea, such as C++ which uses the term "member function calls" (and which is expressly distinguished from mere "function calls").
Aside note: Member function calls are different in that there's no object-dependent selection of function body to select for the call. (I'm skipping a discussion of virtual vs. nonvirtual member functions here, to keep this a small aside note.)
Now, in the sense of full disclosure, I have done far more practicing of law than hacking since I left graduate school and since I sold my software publishing businesses. Accordingly, my libraries haven't been kept entirely up to date.
Hah! Caught you! :)) Seriously, I appreciate this. I hope we can cool down the battle heat a bit.
It may be that the more traditional uses have ultimately been usurped and wholly preempted by the term "member function call."
Probably. The only contestor for OO terminology has been Simula (which predates Smalltalk by a bit if I'm right). And Simula never had that evangelic drive that's inherent in Smalltalk's idea of creating a new paradigm of computing, so the Simula terminology never quite made it into the OO mainstream. (Just representing the situation; I don't see evangelism as a good or bad thing in itself.)
There's one aspect to my argument that I'd like to add to complete the picture: Mainstream terminology isn't just OO terminology. The mainstream outside the OO arena uses words like "subroutine" and "subroutine call". I maintain that there's enough overlap between the concept of a subroutine and a method that this should be acknowledged in some form. I think that the extent of the overlap wasn't obvious initially, so I don't hold the terminology against its creators. But I think the similarities should be clearly spelt out; erecting artificial terminological barriers is doing both Smalltalk and the computing community in general a disservice.
I hope this discussion has been helpful in shedding some light on the concepts that we all thought we knew; I've certainly learnt something here, even if I don't fully disagree with everybody else's point of view.
Regards, and thank you all very much, Joachim
squeak-dev@lists.squeakfoundation.org