Message Oriented Programming

Message Oriented software systems exist -- ServiceOrientedArchitecture, and so, but they don't generally correspond to a language paradigm, because they are generally written in multiple languages. Message Oriented Languages are rare to non-existent If you did have a language that actually worked that way, not just as a metaphor, you might have something sufficiently based on MessageOrientedProgramming to please AlanKay.

What is the difference between a message send and a method call? A message send is dynamic, a method call static. Various things stem from that. Message receivers can for instance choose to ignore messages, relay them, or handle them in different ways. The message is in effect, a request, not a command. MOP is a departure from strictly imperative programing.

SmalltalkLanguage uses DynamicDispatch, so it is message orientated..but not enough to satisfy AlanKay. A functional language can be defined as a language where functions are first class citizens. Smalltalks messages are not first class citizens, separable from message sends; they cannot be composed piece-by-piece and their syntax is limited. (A class interface wants to be a language).

A distributed system consisting of clients accessing a StructuredQueryLanguage database does not have any of those limitations. SQL is a rich language, maybe even too rich. SQL requests are often built up in several stages by clients. The system is truly message-orientated, but a language it is not.

I am in the process of completing a Message Oriented Language MOL that uses flexible messages at the macro level that can be generated by a language command or by creating a first class message variable. These messages are arbitrary Maps (bags of variables) that can be sent to flexible interfaces (on the same computer or distributed) rather than parameters of a function which are fixed in number and type.

At the local level, I provide normal functions that use parameters like all other languages. The idea is to provide the flexibility of messages at the macro level and also to provide the efficiency of function calls at the local level.

Sometimes language ideas can get blogged down by what is rather than what can be! -- DavidClarkd

Hey, nice term. I was in the process of trying to convince the Python community of adding a message-passing paradigm into the language (see also PythonThreeThousand). Instead of a hundred different method invocations, passing data in and out, you have one: a standard operator (>> and <<) that every class can and likely should have/use. --MarkJanssen

Replacing explicit method definitions/invocations with a communications protocol, taken to its logical extent, will bring you right back to explicit method definitions/invocations. For example, how does sending an object a message to request that it add two numbers differ from invoking an object method to add two numbers?

You have an ObjectOriented software system. A few objects are involved in a given message (a.k.a. method call). Which object should handle the message?

The MessageOrientedProgramming answer is "None."

http://www.research.ibm.com/messagecentral/mop.htm

:This link is dead.

At first, this looks like regression to structured programming, or putting all the behavior into one big "actor" class, leaving all the other classes as data bags.

Upon further inspection, it's reminiscent of double-dispatch, and patterns like Visitor, where a couple of classes negotiate to find the behavior that responds to the message.

Then it looks like the Facade pattern, with a broker providing a facade to all the classes in the system under discussion.

Finally, it triggers the memory of that AlanKayOnMessaging quote where he talks about regretting the term "Object-Oriented Programming", specifically the "object" part, since now people are focused on the objects themselves, instead of on the space between them (their interactions).

Is there a real problem here that MessageOrientedProgramming is solving? Or is it just people forgetting to shield themselves with Facades in the appropriate places?

Can we hijack the term to mean, "ObjectOriented, only quit looking at the objects already" ?

:of course you can recreate MOP in OOP...after all you can recreate ObjectOrientation in ProceduralProgramming, etc, etc. TuringComplete is Turing Complete. But we have good reasons for not writing everything in machine code.

Very few object-oriented applications are "pure" object orientation. Eventually, resuability and independence breaks down at the very top: the application designer creates a main form, where all the Buttons and ListBox? objects become heavily coupled, and start referencing each other.

MessageOrientedProgramming could be an example of that habit of the Main Form, but burrowing a little deeper than the surface; you create a series of objects in your application that all have a 'myMainForm' field in them, and an event in one of the form's sub-objects needs to let the other objects in the form know of it.

MessageOrientedProgramming could be considered a slightly less disciplined form of ObjectOrientedProgramming, and might be the same thing as the Mediator pattern.

How does this relate to EventDrivenProgramming?