PROS 4.0.1 Motors/Motor Group Design

[Richard-Stump]

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 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 get_all_* 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.

[djava]

This sounds much nicer, I appreciate this decision 👍👍

[Richard-Stump]

Closed since #532 implements this.