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

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-03-03 11:00:31

Hello João,

----- Original Message ----- 
From: "João Henriques" <jotaf98_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 03, 2008 3:50 PM
Subject: Re: [boost] "Component-based" library (request for critique)

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

Your post do not introduce at all a library, but only a way to write code.
This could explain that there was not too much interest. Be patient.

Maybe you have some features the library will provide or some source to 
attach?
Could you send us something more?

>
> "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; };
>> };

Your example reminds me the Role Object Pattern (or subjective programming).
The Entity will be the subject, the components the roles and the entity is 
missing. Ent1, Ent2 are instances of the subjects with a statical role 
binding.

>>
>> 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
>>

I have just some questions.
. What about the construction of non default constructible components?
. Can we recover the entity instance from a component instance?
. Can we attach/detach a component to/from an entity?
. Why do we want to build classes using different components, worrying as 
little as possible about the specific details of these components? What's 
behind this?
Could you give us some examples where such a library could be a must?

Regards

____________________
Vicente Juan Botet Escriba