Summary

Details

position ease box interval due
front 2.50 2 1.00 2021-10-20T16:06:00Z

stackoverflow answer:

In order to better understand Alan Kay’s Messaging Metaphor, we have to look at a little bit of personal and historical context.

Alan Kay’s Bachelor degree is in Mathematics and Microbiology, and indeed, the idea of Messaging was influenced by the way biological cells interact with each other.

At the same time Alan Kay worked on the foundations of OO, the ARPAnet (that would later become the Internet) was in the process of being invented. It didn’t exist yet, but the ideas were in the air, and Alan Kay knew some of the people who would a couple of years later create it. Plus, he worked at Xerox PARC, where at the same time not only Smalltalk was created but also the Ethernet was invented. So, networking played another important role.

Alan Kay envisioned objects to be like little computers on a network. They have their own private RAM, which no other computer can access (“instance variables” in Smalltalk parlance, “properties” in PHP) and they have their own private code (operating system, libraries, server code, etc.), that no-one can execute (“methods”). The only way to interact with such a computer on a network is to send it a message (call a method), and the only thing you can observe about that computer is the response (the return value). You have no idea how the computer came up with the response: did it look it up in RAM (return a property)? Did it compute it (execute a method)? Did it ask someone else for help (delegation)? Was the message even processed by the computer you thought you sent it to or by a different one (simulation)? You don’t know, you can’t know, and you MUSTN’T know! As long as they speak the same protocol (have the same methods), they are indistinguishable.

(JAK)Analogy  in real world: complex or complicated or any work is possible by interaction between individuals.

  1. message is the foundation: work happens because of messages. person exists(job) to respond to a message.
  2. Trust: one trusts other individual with whom he works with.
  3. Not knowing much about others(Law of demeters): one  asks others(send message) to get  the work done, not caring about how it is done.

It is also similar to how messaging works “in the real world”. If I send you a message, say, a letter, which says “what is 2 + 2” and I get a letter back which says “4”, I have no idea whether you: looked up the answer, computed it yourself, asked someone else to compute it, or if it was even you who answered my question. If have no idea what methods you used, how much help you enlisted, etc. All of this is completely opaque.

Object-Oriented Software Systems, then, are structured as networks of objects that collaborate via messages. And complexity arises through the interactions of those individually simple objects, just like complex organisms with complex behaviors arise through the simple chemical messages sent to each other between individually simple cells.

The term “Object-Orientation” was coined by Dr. Alan Kay, and he defines it thus:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. Let’s break that down:

  • messaging (“virtual method dispatch”, if you are not familiar with Smalltalk)
  • state-process should be
    • locally retained
    • protected
    • hidden
  • extreme late-binding of all things

Implementation-wise, messaging is a late-bound procedure call, and if procedure calls are late-bound, then you cannot know at design time what you are going to call, so you cannot make any assumptions about the concrete representation of state. So, really it is about messaging, late-binding is an implementation of messaging and encapsulation is a consequence of it.

He later on clarified that “The big idea is ‘messaging’”, and regrets having called it “object-oriented” instead of “message-oriented”, because the term “object-oriented” puts the focus on the unimportant thing (objects) and distracts from what is really important (messaging):

Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea.

The big idea is “messaging” – that is what the kernal of Smalltalk/Squeak is all about (and it’s something that was never quite completed in our Xerox PARC phase). The Japanese have a small word – ma – for “that which is in between” – perhaps the nearest English equivalent is “interstitial”. The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet – to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. (Of course, today, most people don’t even focus on objects but on classes, which is even more wrong.)

Messaging is fundamental to OO, both as metaphor and as a mechanism.

A more “modern” term for “messaging” is “dynamic method dispatch(run time polymorphism)” or “virtual method call”, but that loses the metaphor and focuses on the mechanism.

So, there are two ways to look at Alan Kay’s definition: if you look at it standing on its own, you might observe that messaging is basically a late-bound procedure call and late-binding implies encapsulation, so we can conclude that #1 and #2 are actually redundant, and OO is all about late-binding.

However, he later clarified that the important thing is messaging, and so we can look at it from a different angle: messaging is late-bound. Now, if messaging were the only thing possible, then #3 would trivially be true: if there is only one thing, and that thing is late-bound, then all things are late-bound. And once again, encapsulation follows from messaging.

Similar points are also made in On Understanding Data Abstraction, Revisited by William R. Cook and also his Proposal for Simplified, Modern Definitions of “Object” and “Object Oriented”.

Dynamic dispatch of operations is the essential characteristic of objects. It means that the operation to be invoked is a dynamic property of the object itself. Operations cannot be identified statically, and there is no way in general to exactly what operation will executed in response to a given request, except by running it. This is exactly the same as with first-class functions, which are always dynamically dispatched. In Smalltalk-72, there weren’t even any objects! There were only message streams that got parsed, rewritten and rerouted. First came methods (standard ways to parse and reroute the message streams), later came objects (groupings of methods that share some private state). Inheritance came much later, and classes were only introduced as a way to support inheritance. Had Kay’s research group already known about prototypes, they probably would have never introduced classes in the first place.

Benjamin Pierce in Types and Programming Languages argues that the defining feature of Object-Orientation is Open Recursion.

So: according to Alan Kay, OO is all about messaging. According to William Cook, OO is all about dynamic method dispatch (which is really the same thing). According to Benjamin Pierce, OO is all about Open Recursion, which basically means that self-references are dynamically resolved (or at least that’s a way to think about), or, in other words, messaging.

As you can see, the person who coined the term “OO” has a rather metaphysical view on objects, Cook has a rather pragmatic view, and Pierce a very rigorous mathematical view. But the important thing is: the philosopher, the pragmatist and the theoretician all agree! Messaging is the one pillar of OO. Period.

In his paper On Understanding Data Abstraction, Revisited, Cook also looks at OOP from a different angle: Data Abstraction. He clarifies the differences between the two currently most widely-used forms of Data Abstraction, namely Objects and Abstract Data Types. And he notes that the fundamental distinction is that two instances of the same Abstract Data Type can inspect each other’s representation, whereas two Objects, even if they are instances of the same type, cannot. He calls this Autognosis (Self-Knowledge, meaning an object only knows itself), although I prefer the term Xenoagnosticism (Foreign-Not-Knowledge), since the important thing is not that an object knows about itself, but rather that it doesn’t know about other objects.

Some of the languages that embody this metaphor are Smalltalk, Self, Newspeak, and Io, but you can apply it in PHP as well.