It seems to me to be the same thing as the actor model, but you don't mention it. There are a variety of actor languages out there, including some built on the JVM. Often this happens through libraries rather than through compilers. Erlang is a good example of a hard-core actor language. Scala has a variety of libraries that support actors. One of the more recent and more popular is Akka.
People have been writing about this for a few decades and so I was surprised not to see any references to it. -Ralph Johnson On Sat, Apr 16, 2011 at 10:05 PM, Messaging Design Pattern < [email protected]> wrote: > > Dear List members, > > Please find enclosed a link to a draft discussing the Live or Animated > object design pattern: > > http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.pdf > > Any feedback would be appreciated. This draft also includes additional > information about asynchronous concerns, best practices and implementation > considerations. > > Regards, > Al > > Live or Animated object design pattern > > Intent: This design pattern encapsulates component functionality, > processing (threading) mechanism and the messaging functionality required to > provide the component with independent behavior (a “live of its own” so to > speak). This also means that the component uses its own independent > processing mechanism or thread of execution. This design pattern improves > decoupling, encapsulation and scalability while at the same time reducing > complexity and overall implementation cost. Component functionality, > processing/treading mechanism and messaging mechanism are decoupled > entities, independent of one another. MDP messaging [2] allows the > interchange of information (i.e. messages) between the animated component > and other components or applications. Although decoupled and independent of > one another, processing/threading mechanism and component functionality are > completely encapsulated within a single entity: live or animated object. > > > > *Motivation: *The implementation of traditional multithreaded applications > is a complex undertaking which usually becomes costly, time consuming and > prone to error. Defects related to are often encountered (thread management, > synchronization, race conditions, deadlocks, etc). These software defects > are difficult to avoid, reproduce and isolate. Large multithreaded > applications complicate the problem even further. The degree of complexity > and risk considerably worsens as the number of threads and their > interactions increases. Object oriented applications consist of a collection > of components that interact with each other. In reality, some of these > components should be modeled as live or animated components: They exhibit > independent behavior, a “life of their own”...... > > _______________________________________________ > gang-of-4-patterns mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns > >
_______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
