So from the number of responses I'd say it's not worth pursuiting this any further?... João Henriques "João Henriques" <jotaf98@hotmail.com> escreveu na mensagem news:fpsfje$r37$1@ger.gmane.org...
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
--------------------------------------------------------------------------------
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost