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

From: João Henriques (jotaf98_at_[hidden])
Date: 2008-03-03 09:50:56

So from the number of responses I'd say it's not worth pursuiting this any 
further?...

João Henriques

"João Henriques" <jotaf98_at_[hidden]> escreveu na mensagem 
news:fpsfje$r37$1_at_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