Start refactoring of ObjectFactory

[alxbilger]

Early stage of a simplification of the object factory (now ComponentFactory).

Two unanswered questions:

1. How to treat the template? (related to [Core] Improve UX when defining template of a Component #6161
2. How to select the template (canCreate)? And how to get rid of create?

runSofa compiles, but no guarantee for others.

Current changes allow:

<Node name="root">
    <RequiredPlugin pluginName="Sofa.Component.StateContainer"/>
    <MechanicalObject/>
</Node>

<Node name="root">
    <Sofa.Component.StateContainer.MechanicalObject/>
</Node>

---

By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).

---

Reviewers will merge this pull-request only if

• it builds with SUCCESS for all platforms on the CI.
• it does not generate new warnings.
• it does not generate new unit test failures.
• it does not generate new scene test failures.
• it does not break API compatibility.
• it is more than 1 week old (or has fast-merge label).

[damienmarchal]

I would be happy to discuss this point and it is worth having a look there as there was lengthy discussion on the topic in the past.

If I remember correctly, the general idea was that both canCreate and create should be removed.
The observation was to canCreate/create was mostly used to implement two different things:

• template deduction/inference
• component checking or initialization (regarding input/output correctness checking)

To move forward the idea was thus to:

• 1. move the canCreate code related to templateDeduction in a dedicated mecanism and moving the related code from canCreate into something called deduction rules => (eg: progressive deployement in: [Sofa.Core] Implements a template deduction system in the object factory #3938 then [all] Replace canCreate with the getTemplateFromMechanicalState deduction rule #3987 then [all] Replace the complex canCreate with deductionRule #3992).
• 2. move the initialization checking related code out of the canCreate/create into the init() function. The underlying idea is that an object must always be creatable. It can then be initialized by setting its input data and link, then initialized by calling init(). This was more the kind of move done in: [all] Replace canCreate with init() when approapriate #3990
• 3. refactor canCreate as in [All] Refactor create/cancreate in ObjectFactory #5195

If there is a deep refactoring of ObjectFactory, I would also recommand adding the namespace features and user define aliases suggested in:
#2512 and

And also to remove the use of GetClass which cause a code bloat.

[damienmarchal]

If we are refactoring component factory could we drop this please.

If I remenber correctly this single line is causing a compilation code bloat (just to provide the class name). When we are registering a component into the factory the class name could be passed with a std::string instead of relying a complex custom "reflection" system.

[alxbilger]

For now, the only reason I had to keep this function was to list components deriving from another, using the method hasParent in BaseClass. If we find another mechanism for that (or if we remove this feature), we can remove this usage in the factory.