> subscribe There isn't any subscription with messages, which are sent to the object directly. There isn't any "event bus" or other complex structure. Messages

> subscribe There isn't any subscription with messages, which are sent to the object directly. There isn't any "event bus" or other complex structure. Messages are just a replacement for function calls (including accessor methods, which may be implied). > decoupling That's one of the primary goals. Traditionally function calls required coupling between the call and a single function or multiple functions with vtables or other polymorphism. With messages, the handling of what looks like a function call can be interpreted like an incoming event in event-driven programming. > let object B, if it's interested, handle that That's exactly right, but think of it as: * Object A sends Object B an event (message) * Object B can then handle that event in any way, such as: - calling a function - interpreting the event directly (i.e. all events handled the same) - raising an exception - ...whatever... * Object B then returns the result which becomes the "return value" that Object A. (this part is RPC-like) > now B has to know about A Not at all! I suspect you're thinking of this as a subscription model, which isn't correct. One of the key benefits of messages is that objects never need to know about each other's type (in either direction). Ignoring types and simply sending messages to objects (regardless of their type) is called "duck typing"[1]. As long as an object responds in a useful way to the messages ["year", "month", "day"], it isn't important if the object is actually of type Date. [1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...