[c-linkage]

In OOP as I understood it, messages are first-class entities at the same level as "objects". This is strikingly different from modern OOP languages where a message is conflated with "function calls". This is pointed out in the article: "[I]n Smalltalk, messages 'were not real messages but disguised synchronous function calls', and this mistake was also repeated in other languages[...]".

If a message is a first class entity, then an object can technically have only one "function call" -- receive message.

So that an object can simulate an arbitrary set of functions with arbitrary arguments, the implementation of the "receive message" function cannot impose conditions on the format or content of the message. Instead, the message must be encoded in a self-describing format so that the object can interrogate the message and its contents, and only then decide what to do with that message, up to an including ignoring the message entirely.

To make this more concrete, imagine having an JavaScript object that has only one method: receive messages encoded as JSON strings. With JSON strings we can say that the message is self-describing and is easily parsed by the object. Once the JSON string is parsed, the object can then decide what to do based on the content of the message. This is both a late-binding and a dispatching activity.

It should be clear that the version of OOP does not include anything about types. That's because OOP was designed with LISP-like languages in mind, where symbols were processed and strongly-typed objects. It also means that build-/complile-time checking wasn't possible.

I'd say the modern web with JavaScript and HTTP calls is more like the original OOP design than any modern "OOP"-like programming language.

[dexwiz]

Does send() and method_missing() in Ruby fit that bill? From what I remember from Ruby, and it’s been a while, all method calls are just a message via send() with a symbol and arguments. Normal method calls are just syntactic sugar over this system. With method_missing() you can handle any messages that use a symbol that doesn’t match a method name. You could make the object handle messages in a completely dynamic way.

[meheleventyone]

Yeah I was intentionally not talking about OOP but about messaging because I think the concept quite obviously transcends the programming paradigm and I often use it as you suggest.

That said one way of processing messages is to relate the message name to a method name at runtime and that is quite successful which is where I think the stronger version of that linking comes from in other languages that have static binding. It's still the same messaging concept but the routing is resolved at compile time which has tradeoffs.