3 ms·

So... it's basically event-driven programming? Objects generate events, and other objects are free to subscribe to them and do something in response (or not)?

So... it's basically event-driven programming? Objects generate events, and other objects are free to subscribe to them and do something in response (or not)? I thought of something similar a few years ago, I think it would indeed enable much better decoupling than the current OOP model - instead of object A telling object B "do this" (and thus having to know that object B exists and that it can do "this"), have object A emit an event "I just did this" and let object B, if it's interested, handle that. There's still the problem of "now B has to know about A", but it can be solved with a common event bus and a series of messages defined in a different library - that way both A and B only know about the common library, they can be completely independent of each other. I wrote something like this a few years ago - just added it to my GitHub at https://github.com/mdpopescu/public/tree/master/Snake https://github.com/mdpopescu/public/tree/master/Snake - but I can't say I ever did something "serious" with it. It's one of the things I'd like to actually use in production, like CQRS/ES or Orleans :)

pdkl95 10y ago
> 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/...

pdkl95 10y ago

> 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/...