Is Message-Passing The Same As Function-Calling (in Object Oriented Programming)?

Is there any difference between message-passing and function-calling?
Well, yes, there is.
In this video I explain what the differences and the similarities are – and why those differences may be obvious to people who learnt to program in a procedural language such as C or Pascal but not so obvious to people who learnt to program in an object-oriented language such as Java or C#.

BOOKMARK THE SERIES PLAYLIST

To follow this series in order, bookmark the playlist. New episodes are added to the playlist whenever they are published.

DOWNLOAD SQUEAK
Squeak Smalltalk

DOWNLOAD THE SMALLTALK/V TUTORIAL
I will using the excellent Smalltalk/V Tutorial as the “course text” for this series and I encourage you to download a PDF copy of that too:
or:

SUBSCRIBE TO THE CODE WITH HUW CHANNEL

To be notified whenever I upload new lessons, be sure to subscribe.

WHO IS HUW COLLINGBOURNE?

I’ve been programming since the early 1980s. I’ve written wrote programming columns on Java, C#, Delphi and other languages for “PC Plus Magazine”, “Computer Shopper” and numerous other UK magazines. I wrote the cult adventure game, The Golden Wombat Of Destiny, I have developed programming tools with SapphireSteel Software and I have written programming books published by Dark Neon and No Starch Press. These include books on programming C, C#, Java, Ruby, Delphi and Object Pascal, pointers, recursion and programming adventure games.
All my books can be found on Amazon.

Keep in Touch
==============================

Code With Huw on Facebook:

[camilodeazevedo]

Hope you plan to continue this series! It's very important for people that don't have any contact with Smalltalk and "Message passing OOP".

[perfectionbox]

I actually use message passing in C++ using a mediator class here and there to implement better loose coupling, especially for reflecting state changes in UI. Objects can register to recieve the messages they care about, and senders don't need to know who the recipients are.

[luisz]

Finally!!!! I been waiting for more smalltalk vids :^)

[wizsorcer]

It's a very simple and elegant idea. Imagine a world of people. Imagine each person has a 'role' like lawyer, plumber (etc.). Methods are not floating free in the code structure. Methods belong to objects, which are instantiations of classes. If it's needed to fix a random leakage in the plumbing system it would not be possible to call a function directly (supposing a function/method called fixPlumbing). It is necessary to send the message for bject Plumber, because the methds fixPlumbing is encapsulated in there. There are no 'free hoovering functions'. Everything is inside an object. In this example, the object lawyer would not have the method for dealing with fixing the plumbing system. So it's not calling directly the function. Its asking for the ject to handle the message.

[AK-vxdy]

function calling is as giving orders or force object to do something
message passing is as asking to do something
message passing is very very late binding... practicaly dynamic binding at runtime.
it is also possible with calling but requires special features in run enviroment and/or langugage

[plsreleasethekraken]

I've enjoyed this series a lot. The content is great. I do hope in future videos there is an effort to put together some non-trivial code though.

Superficially, objects and messaging sounds great, but I have rarely if ever seen any application of size and substance that adheres to these principles and doesn't in many places devolve into procedural patterns. Classes end up being like structs in Go or Rust but unnecesarily have to carry around their arbitrary type with them. References are passed into method calls in Java/C# and getters and setters are everywhere, just adding indirection to the private fields.

[DaveLeCompte]

What's the value in being able to send any message to any object?

Your sample of catching the error of 123 not handling asLowercase suggests to me that Smalltalk is doing function lookups at runtime, which reminds me of how Python handles method calls, and indeed, you COULD write a very similar chunk of code to handle the Python exception if you tried to call 123.asLowercase() in Python, but I'm not sure what this gains us.

[RianProvesanoReisSc]

Love this series. The doesNotUnderstand reminds me of Ruby's method_missing.

[kostasgkoutis]

If I am not mistaken, you can simulate message passing in mainstream languages as well:

public interface IMessage
{
bool HasResult {get; set;}
object Result {get; set;}
}

public interface ISmallTalkObject
{
void Handle(IMessage message);
}

This doesnt tell you what kind of message the implementer of the interface accepts, and it can definitely choose not to implement the message at all, to throw exception etc.

[andrewgibson]

I'm not sure. I think the dilution of the idea of message passing to just "invoke method" is sad. There are a whole lot of practises which have grown up around programming (DDD, eventmapping, story mapping) which essentially restore this abstraction (message passing) at the design stage. We took a wrong turn with C++, Java, C# et al. I think message oriented OO will have a come back soon.

[weerawu]

IMO to be different from a function call, message passing should:
1. Not return an error but send a reply message to the caller if the caller implements it.
2. Allow the caller to send the same message to a group of objects. Like when you are in a room and ask for a particular help which you don't know who can do it. Then only the objects that understand the message reply.

[Peregringlk]

I don't see any practical difference between the pattern of "private data + public functions" and the "objects that sends messages to other objects, that requires the receiver to have a method with same name". I don't see any "practical difference" or how this specific abstraction solves any problem that current OO-approaches has issues solving.

For example, dependency injection. For me to create an object A that depends on another object B (because some of its methods requires colaboration by B), I have to make sure B exists before A since I need to pass B as dependency to A in its creation, which create a dependency between objects lifetime which is sometimes very hard to manage. Some people calls this problem the "problem of object wiring". How does Smalltak solve this? If an object A needs help, do A needs to know that B is the object that solves my problem, and so A needs to store/contain a reference to B? Because if it does, then it has the same problem that modern-day OO.

Another example: when A have the information to do something, but A doesn't know how to do it, because it's not its responsability. Usually you rely on a getter: B knows how to do it, but doesn't have the information: A, give it to me and then I do the thing. That completely breaks encapsulation since A is exposing private information and structure through the getters, but no other solution is good since you don't know how to do the "thing". How does smalltalk solve this problem?

Is there any problem that smalltalk solves in a very elegant way that is completely unreachable for traditional OO-languages? How is that abstraction of message passing "superior" to the way OO is understood nowadays?

[laughingvampire]

Well, if you take into consideration Alan Kay's definition of OO then Smalltalk would not be OO, that would be something like the Actor Model, which Smalltalk isn't.

In compiled OO languages in which everything is an object, you do not have the `doesNotUnderstand:` or Ruby's `method_missing` because this is more of dynamic OO languages than a feature of OO. But if you forget to define `doesNotUnderstand:` or `method_missing` then you will get an error.

However you are thinking this wrong, because you are thinking objects are not function, only methods are functions, however if you consider that a function is an object and the message is the list of arguments and that it will dispatch based on whatever data gets from the arguments including the values of them, then you can have a similar behavior.

[johnclapperton]

#doesNotUnderstand: reifies the message into an object itself, which may then be passed as an arguement, for example with the #perform: message to implement proxies to forward messages to objects instantiated from a database byte-string retrieval.

[dataweaver]

In an earlier video, you suggested that message passing implies three of the four key features of object-oriented programming: encapsulation, polymorphism, add a third one which I am not recalling at the moment. In this video, you have effectively added exception handling to that list implied concepts. And you seem to be implying that it's even broader than that. If I'm following your explanation correctly, it seems that small talk in particular and pure object-oriented programming in general (or perhaps we should call it message passing programming?) Also implies parallel programming at distributed programming. Conceptually, every object is acting in parallel to every other object; and encapsulation doesn't just mean that the internals of the object are hidden; it also means that the location of the object is irrelevant. It could be hosted, in theory, on a different computer halfway around the world, running a different operating system. An Application could be thought of as an object, with its API as the messages that it listens for.

Am I understanding you correctly?

[hello_world_]

If there is say an object or actor or whatever with encapsulated state and two calls get called to it at the same time if they both read and change state then state could be wrong like if both increase a counter then i guess anything that changes state should be put in sortve a message queue and only start the second call after the first one ends

[jrstf]

When I first encountered Simula 67 back in the mid 1970's I immediately grasped the concept but could not grasp the implementation. Later I read the Byte magazine Smalltalk article with great interest, it really didn't click with me. Later I came to understand the terminology as only making sense in a distributed program environment. Much later I encountered the Scandinavian language Beta, it too immediately clicked in my head. Beta (and some other languages) had the concept of pattern and object, the pattern being the factory that instantiates objects (though that can also be done at compile time), and the object may contain code which is executed exactly once, when the object is instantiated. I loved this concept because it unifies the concept of blocks, structures, procedures, classes, objects, and threads. It conceptually obsoleted every other compiled OO language that exists. Or maybe it's just my low IQ that keeps me from taking in the entire train wreck that is C++.

[fluffykitties]

great video! a very clear explanation. could you do one on uml class diagrams to explain how these oop concepts translate to that notation? also, if you did a comparison of smalltalk and python that would be interesting to many people i think, people that want to see the traditional/ fundamental oop concepts as they relate to python.

[insanemole]

This distinction doesn't make a lot of sense to me. What it sounds like to me is that you're saying message passing always MUST go hand in hand with dynamic typing. But the compiler CAN statically check if an object will be able to understand a particular message, it's just that Smalltalk's in particular doesn't. But something like the Akka library in the Scala world IS doing exactly that nowadays. (Akka is not an implementation of Smalltalk-like OOB but of an Erlang-like actor system, so this is only an observation of its message passing aspect, but the argument still stands.) And conversely, I CAN try to invoke any method of a JavaScript object with any arguments and the "compiler" will happily accept that - it will only possibly fail at runtime, just as in Smalltalk.
But I do suspect another difference: What I've seen in actor systems is that there, message passing has a lot to do with loosening synchronisation restrictions between "caller" and "callee" - because the default in imperative and pseudo-OOB-languages is to wait for an answer to a method call on each invocation while in actor systems the default is to fire-and-forget messages, then continuing with my own business, which might(!) include awaiting message, including, but not(!) limited to replies to my own past messages. But again, that's in the actor world, so I don't know what Smalltalk does in this respect and if that's part of the original mission statement of OOB? I can imagine that control over multiple concurrent threads was quite a bit different back then...

[gahshunker]

i still don't understand how is this different than modern oop languages. the only difference i see is that smalltalk doesn't have a smart compiler that will tell you that a given class/object method/property doesn't exist before runtime, so that you don't get the error at runtime as with smalltalk.