Latest swig_matlab breaks the SixAxisFTOffsetEstimation example

[traversaro]

If I generate the matlab bindings with jaeandersson/swig@03261ee , and then I run : https://github.com/robotology/idyntree/blob/master/examples/matlab/SixAxisFTOffsetEstimation/SixAxisFTOffsetEstimation.m .
I get the following errors :

No public property unknownType exists for class iDynTree.UnknownWrenchContact.

Error in SixAxisFTOffsetEstimation (line 51)
unknownWrench.unknownType = iDynTree.FULL_WRENCH;

Index exceeds matrix dimensions.

Error in SixAxisFTOffsetEstimation (line 157)
wrench = linkNetExtWrenches(estimator.model().getLinkIndex('l_foot'));

For now we will then be stuck to generate and commit the bindings with the commit jaeandersson/swig@5d3770e .

[traversaro]

The second errors could be related to jaeandersson/swig#51 .

[traversaro]

@S-Dafarra experienced the firsts error with the VisualizerOptions struct.

[traversaro]

I am finally investigating this to support the latest swig with matlab support and finally solve #190 .
Both problems are indeed caused by jaeandersson/swig@32ef224 , that removed the subsref and subsasgn methods from the SwigRef.m base class. As it is possible to see from the modifications in the tests, this means that, if you have a C++ struct like:

struct foo
{ 
    double x;
}

if is not supported out-of-the-box anymore to write to the attribute in the matlab bindings as in the following:

myFoo = foo();
myFoo.x = 4;

but rather the writing of the attribute should be done as:

myFoo = foo();
myFoo.x(4);

Similarly, also the default overloading of the () was lost removing the subsref/subsasgn methods.
The new form of assignment is rather cumbersome, and the "old" form is definitely more user-friendly. In Casadi, the necessary support for access to attributes and to use the () operator has been using the matlabcode instructions inserted in some base classes: casadi/casadi@e9169d4 . However, this is not feasible in iDynTree were the structures that require such methods are not descendant from the same class. For this reason, as far as I can understand the only reasonable solution in the short term seems to introduce the subsref/subsasgn methods back in SwigRef.m, by patching it after it is generated. I am not fully grasping the problem caused by this methods that caused they removing, but for now it is the only solution that I think it is reasonable.

[traversaro]

Fixed in #305 , by adding back the subsref and subsasgn to our own version of SwigRef.m.