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 clear way. it also outline a possible implementation for C#.

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

Since D is way better than Java/C#/C++ (all mentioned in the above 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

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
> clear way. it also outline a possible implementation for C#.
> 
> http://blog.gurock.com/wp-content/uploads/2008/01/activeobjects.pdf
> 
> Since D is way better than Java/C#/C++ (all mentioned in the above
> 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

> 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

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.

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