1. Make a logging proxy that wraps an arbitrary object. Any method you call on the logger, it logs the name of the method, and then invokes that method on its wrapped object.
2. Make a "tee" object. Any method you call on the object, it invokes on its N child objects.
3. Make a "replay" object. Any method you call on the object, it saves instead of executes. Later you can replay the saved method calls by redirecting them onto another object.
Message sends can invoke a method, but they can also go beyond that.
You say somefunk.call (someObject, ...someArgs)
The function executes in the context of 'someObject' meaning it can read and write its fields with expressions like 'this.color = "blue"'.
You could say that somefunk() is a method and you are making a method-call. But it is not a method of 'someObject'. Yet by calling it you CAN manipulate the fields of someObject.
JavaScript is NOT the type of "Message passing/Object-Oriented" system like Smalltalk-80. You can communicate with objects, meaning share information with them, meaning read and write their fields, by means other than their methods only.
The core difference is that messages are interpreted by the object itself. At runtime.
Here is a practical example where the difference is obvious. Let's say you have an object that does business logic. You want to log all of its operations without changing its logic or the code that calls it.
In a method call language, this is a pain in the ass. You have to subclass the original class, override every single method, and call the original logic + logger in every single one of those methods. And after all that work all you get is a lousy logger that's just good for one class and needs to be modified if you add something to the original class.
In a message-passing language, you would create a proxy class that passes all of its messages to the original object, then calls the logger. This implementation would involve writing only one method and would be applicable to absolutely any class/object in the system.
And this is just one out of many, many instances where message-passing allows for elegant solutions while method calls make you miserable.
Obviously it is a definition of normal method calls in Smalltalk.
Even with Smalltalk, he well or poorly do you think setters/getters fit within that description?
… A crucial property of an object is that its private memory can be manipulated only by its own operations. A crucial property of messages is that they are the only way to invoke an object's operations. These properties insure that the implementation of one object cannot depend on the internal details of other objects, only on the messages to which they respond.
Messages insure the modularity of the system…"
pages 6 & 7, [pdf] Smalltalk-80 The Language and its Implementation
http://sdmeta.gforge.inria.fr/FreeBooks/BlueBook/Bluebook.pd...