His views are enticing, but vague. The way I understand it is something like a Cellular Automata.

In a Cellular Automata there's a grid of cells that can be in a variety of states. Then an update event is sent to all the cells. In response, the cells update their state based on their own state and the state of their neighbors.

So if we assume...

Grid => Software System
Cell => Object
Update Rule => Event/Message

Then we have a starting point. Locality differs (unless we define neighbors as objects that are connected), and there isn't one update rule, but a variety of messages/events that objects can respond to.

Having used cellular automata, I'm aware of their power and the awesome global emergence that arises from local interactions. Thinking of this applied to the sphere of objects is breath-taking.

Or perhaps to put it another way, it's an extreme event driven system in which a network of objects forms the architecture, (global?) events define the information flow, and the interaction of these objects defines the system behavior.

Is this understanding correct? If not, I'd love clarification and even examples of code written in this message system (vs. code that's not), to make this concrete.

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1

It doesn't have to be cellular automata. Cellular automata is just one very specific example, and message passing isn't even required for cellular automata to work. Message passing is very useful in a wide array of applications, regardless.
– Robert HarveyDec 5 '14 at 20:33

@gnat: There is indeed some resemblance there, but I'm not sure the question is a dupe. This one seems to focus more on message passing specifically.
– Robert HarveyDec 5 '14 at 20:44

1 Answer
1

When an object of class A sends a message to an object of class B because A wants B to do something specific, that isn't OO (according to Kay's vision.) If A is sending the message to inform B that something has happened (rather than telling it to do something,) that is OO.

A good example of this is an onClick method that informs something that a button was clicked.

A bad example would be the append method on a container. This isn't OO programming, rather it is bog standard modular programming. There's nothing wrong with modular programming mind you, but it is different than OO.

EDIT

I feel the need to defend the above somewhat... Refer to Alan Kay's email that was posted in the question (here). Notice quotes like, "I wanted to get rid of data." Notice how he keeps coming back to the notion of avoiding data in favor of sending messages to objects.

When you tell a container to append, you are explicitly dealing with data. You care whether or not the container's size attribute increased. Whenever a function is called because the caller wants to ensure the called's post-condition, that is a reference to data, either explicit or implicit.

Mr. Kay wanted to avoid that, and this means that OO is about sending messages to inform objects of things happening, not to force them to change their state.

Yesterday read a post hon how to model O.O. Messaging in an application, is just not directly supported.
– umlcatDec 5 '14 at 22:24

4

You're basically describing the Subscriber pattern as it relates to UI, the bane of every Winforms and VB programmer that ever existed (read: Big Ball of Mud). It's essentially the motivation for patterns like MVC and MVVM: to lower coupling and improve cohesion. I don't think this is what Alan Kay meant at all.
– Robert HarveyDec 5 '14 at 22:30

1

@RobertHarvey I think b.inform(event) totally fulfills what Daniel said, and it does not use the pub/sub pattern. You can try to make something usable with pub/sub only, I already experimented with such systems, but they are problematic, because you lose abstraction layers if everything is loosely coupled and there aren't clear dependencies between the objects. I am not sure though that this event only approach works. It is hard to name the methods with it, but I'll try it out.
– inf3rnoSep 21 '17 at 22:44

I checked, "tell don't ask" is about encapsulation or in other words not exposing data. It has probably nothing to do with message passing. Btw. I am not sure what he meant, because message is an overused word and he did not give us the definition in his context. So I think this will remain a mystery...
– inf3rnoSep 22 '17 at 12:55