[SofaDefaultType] Extend TypeInfo to handle containers that are not flat array.

[damienmarchal]

Quick test on what could be a direction to fix issue: sofa-framework/SofaPython3#346

I'm now wonder:

• how to generalize that find more comprehensible names for all that.
• is there room for small refactoring in TypeInfo related to the exisitng containers.

If some of you have suggestion, it is more than welcome.

---

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]

@alxbilger, @fredroy, @hugtalbot I welcome some nameing & refactoring suggestion here.

[alxbilger]

This part of the code is still obscure to me. I need to better understand for a better review.

[alxbilger]

Not the right comment

[damienmarchal]

@alxbilger

Thanks for your relevant question, actually this is why the PR is in wip.

So more details.
Fundamentally the TypeInfo system is a strange beast compose of two things. One is a type-traits API designed to be used in compile time code, one is dynamic interface API. AbstractTypeInfo is the dynamic interface (with the virtual function). The AbstractTypeInfoDynamicWrapper is a façade to "wrap" the compile time TypeInfo type-traits into the virtual one.

The TypeInfo type-traits API has several consistancy issues (probably dating back to pre-c++17 area) mixing a lot of different behavior into a single dynamic API... making things very fuzzy.

In the current status of the PR I just wanted to draft something to have a gimplse of the look and feel of a more modern code architecture (without breaking everything).

Regarding your question about insertion in a vector... the problem is that insert is not a push_back... it means inserting "somewhere" which could of course be implemented on vector. But it would requires a serious work on the AbstractTypeInfo API to make all that consistent.

	set	map	vector	fixed_array
clear()	X	X	X
insert(A)	X
insert(std::pair<key, B>)		X	Y
size()	X	X	X	X
resize()			X
empty()	X	X	X	X

So in short:
! IsFixedSizeContainer => clear(), resize()
isContainer => empty(), size()
isSet => insert(A) and !insert(std::pair<>)

I drafted the general implementation, to illustrate what the current TypeInfo is really doing and how to refactor it: https://godbolt.org/z/srsq3ExPq
extract:

template<class Info>
class AbstractTypeInfoDynamicWrapper : public BaseAbstractTypeInfo
{
public:
    bool size() override 
    { 
        if constexpr(
            Info::IsContainer && 
            Info::Properties::IsContainer)
            return Info::clear();
        throw std::runtime_error("Invalid operation");
    }

    bool empty() override 
    { 
        if constexpr(
            Info::IsContainer && 
            Info::Properties::IsContainer)
            return Info::empty();
        throw std::runtime_error("Invalid operation");
    }

    void setValueInteger(int index, int value) override 
    { 
        if constexpr(
            !Info::Properties::IsSetContainer && 
            Info::Properties::Type == DataType::Integer)
                return Info::setAt(index, value);
        throw std::runtime_error("Invalid operation");
    }
    /// ...
}