OOP Message Passing

Doesn't message passing capture this essence better?

in other words, you don't call functions, you send messages.

https://en.wikipedia.org/wiki/Message_passing#Message_passin...

No mention of message passing? Shame.

Is Smalltalk’s message passing really all that different from methods from other OOP languages? Seems like quite an arbitrary distinction to me.

Message passing is less coupled than functions or "objects" that share bits of state.

what is the proper way of thinking of objects that message passing yields (genuinely curious)?

It's called message passing. It used to be part of the commonly accepted definition of OO.

It's a fuzzy one I'm not sure I understand either.One thing though "tru OO" guys often complain of false message passing based on function call. Others here are hinting at asynchronous vs synchronous. Very likely to be what Kay meant.Another thing to me, is that message interactions mean standalone data exchange. As if to design your interfaces to accept very small but complete objects as communication protocol. Rather than passing structures to be modified. I'm no

One of the major differences, from a programming point of view (as opposed to implementation) is that with message passing, you can pass any message to an object, even if that object doesn't know how to handle it.Cocoa makes extensive use of delegates (not sure if these are similar to .net delegates) for handling unrecognised messages, which makes adding custom behaviour to classes possible without subclassing.Rails is (in)famous for making use of Ruby's method_missing to implement all so