It is much broader than events. Anything where you sit and wait for some piece of data to happen and trigger code can be viewed as receiving messages. An object

It is much broader than events. Anything where you sit and wait for some piece of data to happen and trigger code can be viewed as receiving messages. An object that sits in memory and has its methods called is receiving messages. A piece of code that calls methods on objects is sending messages. A variable containing data is a message at rest, and once passed to a method becomes a message in transit. If you then start thinking about things like generators, you see that this is just another way of sending messages. You can take any program and view it entirely as a collection of messages, with the objects and procedures being the glue between the messages. The issue that languages have, is that the syntax obscures this fact instead of highlighting it. There are many different ways of sending a message between objects, and none of them are labeled as such. But essentially, there are just two different models that matter: synchronous send + receive (receive the replied message, the method's return value, before moving on), and asynchronous send + receive (where the receive remembers the context of what was sent that is being replied to). A really simple OO language would just implement those two operations between objects, and would need nothing else.