agree at 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
-- 
Please don't send unsolicited ads.