Non mutable states

[buschbapti]

One of the idea that come up due to PR #65 is changing the design of State and derivatives to have non mutable objects, i.e. there should be valid from construction and things like set_name(new_name) or set_reference_frame(new_ref) should not be possible unless associated with the correct operations (mainly transformations with CartesianPose). I do think this would avoid a lot of confusions / errors while also reducing the getters and setters hence the inline functions.

[domire8]

I agree that non mutable objects would be a good idea to avoid errors and the user would be forced to use the library like we intend it to. Otherwise there are no limits to what a State can be and can be transformed to 😄

[eeberhard]

+1 for reducing setters and keeping instantiated objects consistent / less mutable.

This matches my current usage pattern of the library; I make an object to represent a particular state (for example end-effector in robot frame), and consistently refer to that object as "ee_in_robot" or similar. If I then need a different representation (say end-effector in optitrack frame), I prefer to create a new object "ee_in_optitrack" from the transform operation. In this way I have both objects still available for control / logging purposes, and my code is more readable because the variable names stay consistent.

The contrasting case is to use a single my_pose object that gets modified to represent different states - perhaps this saves a bit of memory if you don't need to keep multiple representations at the same time, but the loss of clarity and potential for user errors is not worth it.

[buschbapti]

Yes exactly my idea is that we could also have set_reference_frame(const CartesianPose&) that would actually do the operations but on place. This way the setters are actually worthwile and let users do as you suggest but at least they can really trust the result.