• Yigal Chripun (14/14) Apr 19 2008 Active Objects were mentioned in a thread on the NG, so I've looked
• Robert Fraser (21/37) Apr 19 2008 For low-level tasks (i.e. mapping a function to every element of an
• Craig Black (8/15) Apr 21 2008 It is possible to implement active objects such that global state is not...
• Robert Fraser (2/11) Apr 21 2008 Now that would just be awesome.
• Christopher Wright (4/15) Apr 24 2008 You could use dependency injection to give your active object a

Yigal Chripun <yigal100 gmail.com> writes:

Active Objects were mentioned in a thread on the NG, so I've looked
around and found the following file which explains the idea in a very


http://blog.gurock.com/wp-content/uploads/2008/01/activeobjects.pdf


article) it seems to me that such a useful abstraction could be
implemented in D and probably would be simpler to do that than the other
languages mentioned above.

What are the benefits of D's approach of implementing a functional
subset with pure functions compared to the above abstraction of Active
Objects?
Also, to make D's functional subset run Concurrently doesn't D need a
special runtime that parallelizes the code (which D currently doesn't have)?

--Yigal

Robert Fraser <fraserofthenight gmail.com> writes:

Yigal Chripun wrote:
 Active Objects were mentioned in a thread on the NG, so I've looked
 around and found the following file which explains the idea in a very

 
 http://blog.gurock.com/wp-content/uploads/2008/01/activeobjects.pdf
 

 article) it seems to me that such a useful abstraction could be
 implemented in D and probably would be simpler to do that than the other
 languages mentioned above.
 What are the benefits of D's approach of implementing a functional
 subset with pure functions compared to the above abstraction of Active
 Objects?

For low-level tasks (i.e. mapping a function to every element of an 
array), it's easier to write and a better solution using D's model (pure 
functions).

For high-level tasks (i.e. processing a SQL query in large database 
engine), active objects are _MUCH_ easier to work with, since they allow 
state (automatic state within functions doesn't cut it here, fellows). I 
think this is where the future of parallelization lies, not in forcing 
the user to worry about immutability and pure functions (which is not 
easy for the average programmer, I _hated_ learning FP in school).

*puts on flame-retardant vest* Maybe my mind is just too focused on 
database and web programming, but from working with an event-based 
parallelization technique (SEDA, but AO is quite similar in its 
approach, albiet more OO and by a different name), is that it's a lot 
easier to grasp for the programmer. All data outside the event needs to 
be synchronized on, of course, but a good event model uses very little 
global data.

OTOH, D's model is compiler-checkable (i.e. the compiler can guarantee 
you no sync issues), while an event/active object model is not (since 
you can access global state).

 Also, to make D's functional subset run Concurrently doesn't D need a
 special runtime that parallelizes the code (which D currently doesn't have)?

Yes, but that can be done. Active objects would need one, too.

 --Yigal

"Craig Black" <cblack ara.com> writes:

 OTOH, D's model is compiler-checkable (i.e. the compiler can guarantee you 
 no sync issues), while an event/active object model is not (since you can 
 access global state).

It is possible to implement active objects such that global state is not 
accessible via an active object unless the global variable is synchronized 
or thread local (if thread local support were added).  What I am saying is 
that thread safety could be enforced at compile time if the right language 
features were in place.

 Also, to make D's functional subset run Concurrently doesn't D need a
 special runtime that parallelizes the code (which D currently doesn't 
 have)?

 Yes, but that can be done. Active objects would need one, too.

All that would be needed for active objects is a thread pool, which is cake. 
Each active object could just be a task added to the pool.

-Craig

Robert Fraser <fraserofthenight gmail.com> writes:

Craig Black wrote:
 OTOH, D's model is compiler-checkable (i.e. the compiler can guarantee you 
 no sync issues), while an event/active object model is not (since you can 
 access global state).

 
 It is possible to implement active objects such that global state is not 
 accessible via an active object unless the global variable is synchronized 
 or thread local (if thread local support were added).  What I am saying is 
 that thread safety could be enforced at compile time if the right language 
 features were in place.

Now that would just be awesome.

Christopher Wright <dhasenan gmail.com> writes:

Craig Black wrote:
 Also, to make D's functional subset run Concurrently doesn't D need a
 special runtime that parallelizes the code (which D currently doesn't 
 have)?

 Yes, but that can be done. Active objects would need one, too.

 
 All that would be needed for active objects is a thread pool, which is cake. 
 Each active object could just be a task added to the pool.

You could use dependency injection to give your active object a 
threadpool. Or you could use threadPool.createNew!(MyActiveClass) or 
some such.

 -Craig