Reconsider "Message Expression" Terminology

[runpaint]

Is this helpful, or should we return to talking in terms of method invocation? (Re: #21)

[coatl]

How about 'callsite'?

[runpaint]

Surely the callsite is the location from which the message is sent? Depending on context, either the statement comprising the message expression, or the lexically-enclosing construct? Using "method call", or a similar phrase, would certainly have the benefit of familiarity, but its connotations are...unfortunate. For me, they evoke images of an early-bound, statically analysed language. Given a diff with a method call, m, you could reason that a method of that name exists in the current file, or one of a few possible alternatives.

Is your objection to an unfamiliar term, per se, or this term and how it has been defined?

[coatl]

My objection to 'message expression' is that is unfamiliar and unusual. I have never before encountered this term in verbal conversation, on the mailing lists, or in a book. A quick search of blade.nagaokaut.ac.jp reveals exactly 2 emails there which use this phrase; one from 2001 and a second from 2006 which is really about Io. Whereas 'method call' returned over 4000 results. (Some of those would have been duplicates, no doubt.) So it's clear that 'method call' is more familiar to rubyists.

I'm very confused about why you think 'method call' has some kind of static connotation to it. Yes, it is used for static languages such as Java and C++. But so what? It applies equally well to dynamic languages such as ruby as well. It is simple and direct and accurate. Are these not calls to methods that we are talking about?

I proposed 'callsite' as a compromise because you didn't like 'method call'. It's a technical term used by compiler writers, usually to refer to the virtual or physical instruction(s) which set up before, clean up afterward, and actually cause a call to happen. I believe it is also valid to apply it to calls as represented in other stages of compilation, such as the intermediate representation, AST or even source code. (At any rate, I use it in those contexts as well. For whatever that's worth.) I wouldn't really say that it's valid to apply it to whatever syntactic context contains the call. I don't like it as well as 'method call', as it's less familiar and perhaps a slight misapplication, but I think it's more appropriate than 'message expression'.

[coatl]

Oh, I just noticed that you used the term 'method invocation' to start off this thread. That one would be ok as well.

[runpaint]

Unfortunately, probably due to the dearth of English-language documentation, Ruby's history is littered with inconsistent terminology. As I wrote in the Messages chapter, Smalltalk was the basis for Ruby's misappropriation of the term 'message', yet Smalltalk, due to its academic background, was consistent in separating 'message' from 'method'. If 'message expression' becomes 'method ....', the term 'message' no longer makes sense. Which invalidates the entire Messages chapter, so that will need merging with the Methods chapter. But then that curtails my use of the terms 'selector', and, to a lesser extent, 'receiver'. Fine, so we're now speaking in the lingua franca. Nobody needs to learn any terminology. But in the process we've lost all of the subtleties inherent in the 'message' lexicon; we've papered over the distinction between messages and methods. A 'method call' invokes a method, sure, but which method? A method call presumably includes the 'method name', which may not correspond to any known method. Or, if it does, it may refer to one by a different name. Anyway, if I do have to scrap all my carefully crafted explanations, I want to be certain that the status quo is desirable, so I suspect I'll need to ruminate some more. :-/

[coatl]

I should go read the chapters you mention, so I have a better idea what the issues are. I should that a drastic re-write is not necessary..... I have to admit that I'm not a big fan of the term 'message' in this context anyway. (Not a smalltalk user.)

Perhaps you should seek some opinions other than mine, tho.