archives

Actors vs. Reactive Objects

In their paper Reactive Objects the authors compare reactive objects to the actor model (at the end of the Related Work section). They give three advantages reactive objects have over actors:

  1. messages to undefined methods are simply queued
  2. the Actor model lacks synchronous messages
  3. asynchronous message delivery is not order-preserving

These may have been true of the original Actor model but a modern implementation seems to feature improvements to all three points. For example, on point 2, Io features both synchronous & asynchronous message passing, where you either synchronise on the result, send the message asynchronously (prefix any message with @ and be given a future that transforms into the final result when known) or send it & ignore the result (prefix any message with @@). Undefined messages are sent up the inheritance chain, and asynchronous message delivery is handled on a first-in first-out basis.

What alternative do reactive objects offer on point 1? I've not managed to work that out from the paper. Any pointers would be appreciated! I'm basically trying to situate Reactive Objects in comparison to the Actor model, functional-reactive programming, and other means of situating software as a means of responding to it's environment rather than the other way around (particularly in relation to GUI research).