The current design for Motors, Motor Groups, and their relation is not well liked and goes against C++ norms. We are reverting back to the original idea since the better maintainability does not out weigh the priority of a good API.
Proposal:
Motors and motor groups inherit from a class named AbstractMotor like originally planned. This class is not constructable (as it is abstract) and contains virtual methods for functions from motors and motor groups
The motor's move functions. For motor groups, they tell all the motors in the group to move uniformly
The motor's set functions. For groups, they set the parameter for each motor uniformly
The motor's get functions: For groups, they get the value from the first motor
The motor group's getall* functions. For motors, they return a vector of 1.
We are also removing the OOP features from the motors/groups since they caused too many issues. The constant calls to send the parameters caused issues. We're moving the OOP reversed flag to the C api level.
Looking for any more thoughts and considerations on this.
Background
The current design for Motors, Motor Groups, and their relation is not well liked and goes against C++ norms. We are reverting back to the original idea since the better maintainability does not out weigh the priority of a good API.
Proposal:
Motors and motor groups inherit from a class named
AbstractMotor
like originally planned. This class is not constructable (as it is abstract) and contains virtual methods for functions from motors and motor groupsWe are also removing the OOP features from the motors/groups since they caused too many issues. The constant calls to send the parameters caused issues. We're moving the OOP reversed flag to the C api level.
Looking for any more thoughts and considerations on this.