Decide at which level an user can interact/command the class composing a filter

[claudiofantacci]

The current implementation seems a bit too restrictive.
While this has the advantage of reducing implementation mistakes for filters, in some context it seems too restrictive. As a results some easy implementations become way too problematic.

[claudiofantacci]

It is probably better to always provide access to all classes.
As an example, expose the motion model from a prediction class instead of restricting the access from the setProperty() method.

[claudiofantacci]

We should get rid of setProperty() and implement reset() and freeze() functions for

1. Agent and derived classes
2. ExogenousModel and derived classes
3. StateModel and derived classes
4. MeasurementModel and derived classes

[claudiofantacci]

This issue should become an Epic and split into 4 issues of 5 points each.

[xEnVrE]

We should get rid of setProperty() and implement reset() and freeze() functions

I am not convinced anymore about this choice. Sometimes, a user may want to communicate with a class for reasons different from resetting or freezing - using the standard interface of StateModel and MeasurementModel.

As an example, I have some code like this in a class inheriting from MeasurementModel

bool iCubObjectMeasurements::setProperty(const std::string& property)
{
    bool outcome = ObjectMeasurements::setProperty(property);

    if (property == "use_contacts_on")
    {
        use_contacts_ = true;
        outcome &= true;
    }
    else if (property == "use_contacts_off")
    {
        use_contacts_ = false;
        outcome &= true;
    }
    else if (property == "get_contact_state")
    {
        return (tactile_data_size_ > 0);
        outcome &= true;
    }

    return outcome;
}

where I am using setProperty to enable/disable use of contact points in the measurement model. This is useful in case I want to enable/disable this feature from an asynchronous RPC call using something like this inside the main filtering class

rpc_method_for_contacts_on()
{
    correction_->getMeasurementModel().setProperty("use_contacts_on");  
}

In the example above, I am also using setProperty to get some information from the measurement model class, i.e. using

else if (property == "get_contact_state")
{
    return (tactile_data_size_ > 0);
    outcome &= true;
}

to known whether there where contacts or not - of course this is a very ugly implementation. Maybe, we need also a getProperty method then.

What do you think @claudiofantacci ?

[claudiofantacci]

Thanks for the feedback. I get the point and in particular that the function setProperty has been vastly used over its nominal scope.

I understand that you may need to set something to a filtering object other than freeze and reset.
As a consequence, we could implement freeze(), reset() and change setProperty(std::string) in something like set_property(std::string, any::any). However, I would never use a set method to get something and I would expect a public method to do it. If this is required, we need to change the interface so that classes can also return a property, e.g. with any::any get_property(std::string).
Note however that by using these methods the filtering recipes (the algorithms) will have custom commands here and there losing generality.

Probably the idea of generality is way too restrictive in this context and we should just provide classes and utilities to ease and speed up the implementation of filtering algorithm.

[claudiofantacci]

PS

else if (property == "get_contact_state")
{
    return (tactile_data_size_ > 0);
    outcome &= true; // <--- this line is never evaluated.
}