RE: [boost] Re: [Threads] Simple active object wrapper, take 2

From: scott (scottw_at_[hidden])
Date: 2004-02-29 22:53:16

Hi Mark,

You have introduced a third perspective - looks promising. Hope
I can keep track of all the differences and still contribute in some
useful manner.

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Mark Blewett
>

<snip>

>
> class MyServant : public Servant
> {
> public:
>          MyServant(Scheduler* scheduler) : Servant(scheduler) {}
>          void do_fn(int x, int y) { std::cout << x << " " <<
> y << std::endl; }
> };
>

> class MyServant : public Servant
> {
> public:
>          MyServant(Scheduler* scheduler) :
> Servant(scheduler), fn(this,
> &MyServant::do_fn) {}
>          MethodProxy<MyServant, int, int> fn;
> private:
>          void do_fn(int x, int y) { std::cout << x << " " <<
> y << std::endl; }
> };
>

<snip>

I understand the direction that both Matthew and yourself are heading. The
resulting interface for clients of your class, is concise. Fully bound
functions
are a nice packaging and there are plenty of precendents. There is one
design
constraint that this direction would impose on clients, that rules it out as
a solution for me. This doesnt necessarily interest you but just in case, I
will try to paint the picture as briefly as I can.

If active objects (i.e. classes deriving from Servant) communicate by
calling
methods defined in each other, then they have compile-time knowledge of each
other. Reasonable assumption I suppose. However, it follows that every
client of a
particular object, i.e. an active object that calls a member of another
active
object, is itself required to provide a specific interface. That being the
interface that the second object uses to respond.

Returning to the db server example; every client must derive from a common
class that defines all the members that the server might call. Perhaps like
this;

class DbServant : public Servant
{
public:
        DbServant(Scheduler* scheduler) :
        Servant(scheduler), fn(this,
                &DbServant::do_fn) {}
                MethodProxy<DbServant, int, int> fn;
private:
        void do_fn(int x, int y)
        { std::cout << x << " " << y << std::endl; }
};

class MyReadOnlyViewer : public DbServant
{
        // Run a status display repeated around
        // the factory
};

class MyViewerAndController : public DbServant
{
        // Run a window with controls
        // for modifying the data model
};

This (hopefully) seems like a reasonable circumstance. But as coded the
db_server would be calling methods defined in DbServant when what you
really want is different implementations for MyReadOnlyViewer and
MyViewerAndController. I assume that with some twiddling your technique
could accomodate these kind of requirements (given that you are still
reading and still interested).

Would the db_server also have a separate "db_interface" class?

Also, if this kind of interface class technique has any legs is it
also (potentially) dragging lots of implementation details along
with it? Can that be avoided? Should it be?

Cheers,
Scott