3

In Smalltalk we say "send a message to an object", but is it also correct to say "send a message to an object" in Java, or is it only correct in Java to say "call a method of an object"?

1
  • 2
    How do you define "correct?" The usual verbiage is "calling a method." "Sending messages" is generally reserved for things like email and messaging queues. If you say "send a message to an object" when you mean "call a method," most folks won't know what you are talking about. Commented Oct 30, 2020 at 21:34

4 Answers 4

2

"Sending a message to an object" is indeed smalltalk syntax and semantics which is slightly different than method invocation (brilliantly and concisely explained in this SO answer).

But "Sending a message" is also used to describe object interactions in UML sequence diagrams: this makes this terminology de facto programming language-independent OO terminology.

It is therefore "correct" (i.e. defendable with objective arguments in a discussion) in any OO programming language, Java included. However, in a pure Java context, it might sound weird: "method calling" is more accurate and less ambiguous, since "message passing" is often used to refer to IPC and network communications.

2
  • This is an interesting point. I'll try to dig deeper into the origins of the UML terminology. As both UML & Java appeared around 1995, it's hard to say whether UML "summarized" the concepts of common OOP languages including Java, or whether ULM describes the conceptual direction how things should happen, but Java went it's own way. Also, who uses UML nowadays?
    – Uko
    Commented Nov 1, 2020 at 20:12
  • 1
    @Uko Thank you. I saw on SO you’re quite knowledgeable on Smalltalk. UML took over the sequence diagrams from Booch (before 1993) which emerged in a pre-java c++ culture and was already using messages with the simple definition of “an operation that one object performs upon another. The term message, method, and operation can be used interchangeably”. So very method oriented: sender is responsible. The UML definition was generalized: “a message is a communication in which a sender makes a request for either an operation call or a signal receipt by a receiver”. so receiver remains responsible.
    – Christophe
    Commented Nov 1, 2020 at 20:33
2

While this is just terminology, "sending a message" is a very strict concept in Smalltalk which defines how you program, and it can't be followed to a full extent in Java.

In Smalltalk when you see code like:

anObject doSomething

you know that the object behind the variable anObject will receive the doSomething message. Then you have no idea what is going to happen (of course you can assume what kind of object you have and how it will respond, but conceptually that's it). On the other side, when the object receives your message it will:

  1. Use its own method that matches the message's signature to reply
  2. Lookup the method in the inheritance hierarchy
  3. Execute the doesNotUnderstand: method (which by default rises the "message not understood" exception but can be overridden like everything else.

In Java it's hard to explain everything as "message sends" because there are my other ways how things work. Imagine this example:

String text = "value";
System.out.println(text.length());

You can say that you send the message length() to the object behind the text variable. But what happens in this case:

String text = null;
System.out.println(text.length());

it still looks the same, but no object is receiving the message, because null is not an object in Java (while it is an object in Smalltalk).

One can come up with many examples like this one, but while Smalltalk was built around messages, Java just borrowed some ideas from Smalltalk. Thus it's clear that some concepts of Smalltalk are not fully applicable to Java

0

Both SmallTalk and Java are object-oriented languages. Message-passing in SmallTalk is just another way of saying "calling a method," but the focus is on abstractions.

Passing messages between objects was meant as an illustration to differentiate OO languages from procedural languages of the day. The focus is more on the way objects interact rather than the specific algorithms that manipulate data. Passing messages implies the sender of a message does not know the details of how that message is processed, and doesn't need to. The message sender deals with an abstraction, rather than something concrete.

Since Java is another object-oriented language that supports similar levels of abstraction, the same concept applies.

1
  • 1
    I would add that one non-terminological difference here is how Smalltalk reifies messages. Every object has a #doesNotUnderstand method that you can potentially override (the default implementation in ProtoObject just throws a MessageNotUnderstood). It's as if every object in SmallTalk is also a Java dynamic proxy object, that can handle any arbitrary message sent to it.
    – Alexander
    Commented Oct 31, 2020 at 1:17
0

I would argue that the term “message sending” is on the one hand useful as an abstract concept to describe a way to think about object oriented programming. In this regard it might be uncommon but you could talk about any object oriented program this way, including one written in Java.

But then there are languages that really implement “message sending”. This is done for example in Smalltalk and in Objective-C. It would not be a correct description of the way Java decides which method to execute.

There is a question on this site that discusses a similar problem: So what did Alan Kay really mean by the term “object-oriented”?

And Alan Kay did comment on one of the answers himself:

I was too blythe about the term back in the 60s and should have chosen something like “message oriented”

You could also have a look at the answers to What's so special about message passing in Smalltalk? on StackOverflow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.