Jeff Garland wrote:
Sure, but the point of the active object is that the concurrency approach is a detail is hidden behind the interface of the object.
It's clear that you're using a broader definition of "active object" - any object that provides an asynchronous interface. I'm not, I'm interested in the specific case of:
The classic active object idiom, as I understand it, deals with the shared state problem by implicitly serializing the method calls via a message queue, so that concurrent access to the state is eliminated.
The significance of the classic definition is that you can take an existing single threaded object and turn it into an active object _automatically_. In Concur, for example, the language can do that for you; the various proposals for a Boost implementation do something similar. If you use the broader definition, AO becomes a pattern, and you can't implement it in either the language or the library.
If you haven't already you might want to have a look at this paper:
I will, thank you.