[boost] "Component-based" library (request for critique)

From: João Henriques (jotaf98_at_[hidden])
Date: 2008-02-24 14:12:46

Hi there, I haven't posted to the boost mailing lists except for the Spirit
group, but I've been a user for some time. I'm still not sure if this is the
right place to post this.

The main reason why I came to this list is that I need some real critique on
this library of sorts and if you think it's good enough, it might be
submitted as an actual addition to boost. What scares me the most is the
huge amounts of "boostification" that it probably needs, but I'm willing to
give it a try.

For those not familiar with component-based design, it can be put very
simply as a "programmer-friendly" form of multiple-inheritance: we want to
build classes using different components, worrying as little as possible
about the specific details of these components. The fact that a class has a
specific component is also not known in advance, but user code must be able
to access any component-based class through the same interface. The simplest
piece of code can produce this effect:

class ComponentA {
public:
    int x, y;
};

class ComponentB {
public:
    int i;
};

class Entity {
public:
    virtual ComponentA* a() { return 0; };
    virtual ComponentB* b() { return 0; };
};

class Ent1 : public Entity {
public:
    ComponentA _a;
    ComponentA* a() { return &_a; };
};

class Ent2 : public Entity {
public:
    ComponentA _a;
    ComponentA* a() { return &_a; };

    ComponentB _b;
    ComponentB* b() { return &_b; };
};

Ent1 only uses ComponentA, so ent1.b() returns a null pointer. In a more
pratical example, many "virtual components" would be defined in the base
class Entity, but only a handful would be overrided by the derived classes
and actually used. Treating an instance as the base class, it's easy to
inspect whether it has a given component or not. No downcasting is ever
needed. The inclusion of each component as member instead of taking the
multiple-inheritance approach avoids any name conflicts and "ambiguous
usages"; so a component can be written as a self-contained class, not
worrying about the outside world at all.

I realize this example is trivial and anyone could come up with a similar
system on their own. What interests me is the sistematic usage of this
technique and the definition of a common interface that turns each of these
definitions into a one-liner. The most useful implementation of these ideas
allows "dynamic components" on top of the ones burned into a derived class,
and any component at all can be enabled or disabled (with relevant
constructors/destructors called), without any knowlege of whether it's
dynamic or permanent. Accessing dynamic components incurs some overhead, but
for the other ones it is the minimum possible.

So, in conclusion, I'd like to know what you think. Maybe this is a trivial
system not good enough to be called a "library", maybe it's useful but not
Boost material, or maybe you think that after some work it could be a nice
addition. What I want is some critique. If you think it's worthwhile, I can
provide the final code (with dynamic entities and all) for you to review.

João Henriques