[I understand that this this could be seen as a rather theoretical question, but I think it has real-application impact].

"Academic" base
With a component-based design one wants to get rid of the long inheritance chains known in larger games ("deadly diamond of death"). So we create a BaseComponent class that handles all the administrative chores (ID and type handling, possibly a generic list of properties, ...).

Now each actual Componentshould inherit from that base [start of academic/dogmatic flair] and only that base [end].

Concrete situation/example:
Assume I have three components with different attributes:

1. Person: age, name, gender, isTired, isSick, ...
2. Guest: satisfaction, desires, ...
3. Employee: current duty, shift end, ...

Now in traditional OOP design, Person would act as the base class for the other two. As I currently "forbid" that type of inheritance for the components in my project, everytime I am e.g. processing my employees and checking/updating their state attributes I have to either use some helper function to access the sibling component Person (if it exists) or send a message out that hopefully Person will be registered for and will process. Or I can simply assume that each Guest and Employee always will have the component Person. But then I might as well let those two components inherit from Person, so they for example both have the member functions to manipulate some specific properties.

Note: There will never be an Entity that has the component Employee, but not component Person (same applies to Guest). They are a fix requirement, which is why I am considering inheritance here at all.

Question: My question is now whether anyone can see any real-life problems that would be introduced by (re-)incorporating a bit of inheritance into my components other than to a degree violating the original base/dogmatic concept and the risk that (if used excessively) I would end up with the exact same problem the component-based design tried to solve in the first place?

References:
Thread that ultimately led my to asking that question, showing such inheritance.

[I understand that this this could be seen as a rather theoretical question, but I think it has real-application impact].

"Academic" base
With a component-based design one wants to get rid of the long inheritance chains known in larger games ("deadly diamond of death"). So we create a BaseComponent class that handles all the administrative chores (ID and type handling, possibly a generic list of properties, ...).

Now each actual Componentshould inherit from that base [start of academic/dogmatic flair] and only that base [end].

Concrete situation/example:
Assume I have three components with different attributes:

1. Person: age, name, gender, isTired, isSick, ...
2. Guest: satisfaction, desires, ...
3. Employee: current duty, shift end, ...

Now in traditional OOP design, Person would act as the base class for the other two. As I currently "forbid" that type of inheritance for the components in my project, everytime I am e.g. processing my employees and checking/updating their state attributes I have to either use some helper function to access the sibling component Person (if it exists) or send a message out that hopefully Person will be registered for and will process. Or I can simply assume that each Guest and Employee always will have the component Person. But then I might as well let those two components inherit from Person, so they for example both have the member functions to manipulate some specific properties.

Note: There will never be an Entity that has the component Employee, but not component Person (same applies to Guest). They are a fix requirement, which is why I am considering inheritance here at all.

Question: My question is now whether anyone can see any real-life problems that would be introduced by (re-)incorporating a bit of inheritance into my components other than to a degree violating the original base/dogmatic concept and the risk that (if used excessively) I would end up with the exact same problem the component-based design tried to solve in the first place?

References:
Thread that ultimately led my to asking that question, showing such inheritance.

[I understand that this this could be seen as a rather theoretical question, but I think it has real-application impact].

"Academic" base
With a component-based design one wants to get rid of the long inheritance chains known in larger gamees ("deadly diamond of death"). So we create a BaseComponent class that handles all the administrative chores (ID and type handling, possibly a generic list of properties, ...).

Now each actual Componentshould inherit from that base [start of academic/dogmatic flair] and only that base [end].

Concrete situation/example:
Assume I have three components with different attributes:

1. Person: age, name, gender, isTired, isSick, ...
2. Guest: satisfaction, desires, ...
3. Employee: current duty, shift end, ...

Now in traditional OOP design, Person would act as the base class for the other two. As I currently "forbid" that type of inheritance for the components in my project, everytime I am e.g. processing my employees and checking/updating their state attributes I have to either use some helper function to access the sibling component Person (if it exists) or send a message out that hopefully Person will be registered for and will process. Or I can simply assume that each Guest and Employee always will have the component Person. But then I might as well let those two components inherit from Person, so they for example both have the member functions to manipulate some specific properties.

Question: My question is now whether anyone can see any real-life problems that would be introduced by (re-)incorporating a bit of inheritance into my components other than to a degree violating the original base/dogmatic concept and the risk that (if used excessively) I would end up with the exact same problem the component-based design tried to solve in the first place?

References:
Thread that ultimately led my to asking that question, showing such inheritance.

[I understand that this this could be seen as a rather theoretical question, but I think it has real-application impact].

"Academic" base
With a component-based design one wants to get rid of the long inheritance chains known in larger games ("deadly diamond of death"). So we create a BaseComponent class that handles all the administrative chores (ID and type handling, possibly a generic list of properties, ...).

Now each actual Componentshould inherit from that base [start of academic/dogmatic flair] and only that base [end].

Concrete situation/example:
Assume I have three components with different attributes:

1. Person: age, name, gender, isTired, isSick, ...
2. Guest: satisfaction, desires, ...
3. Employee: current duty, shift end, ...

Now in traditional OOP design, Person would act as the base class for the other two. As I currently "forbid" that type of inheritance for the components in my project, everytime I am e.g. processing my employees and checking/updating their state attributes I have to either use some helper function to access the sibling component Person (if it exists) or send a message out that hopefully Person will be registered for and will process. Or I can simply assume that each Guest and Employee always will have the component Person. But then I might as well let those two components inherit from Person, so they for example both have the member functions to manipulate some specific properties.

Note: There will never be an Entity that has the component Employee, but not component Person (same applies to Guest). They are a fix requirement, which is why I am considering inheritance here at all.

Question: My question is now whether anyone can see any real-life problems that would be introduced by (re-)incorporating a bit of inheritance into my components other than to a degree violating the original base/dogmatic concept and the risk that (if used excessively) I would end up with the exact same problem the component-based design tried to solve in the first place?

References:
Thread that ultimately led my to asking that question, showing such inheritance.