-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨PROS4: Base Class for Motors #532
Conversation
Changed every to all naming scheme
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me so far. Just a couple things that I noticed, but I couldn't find any functions that were missing nor any spots in the C-API where the port's sign wasn't checked.
I think I prefer the name |
This was tested and confirmed to work on real hardware. Indexed setters/getters were tested, vectorized setters/getters were tested, and polymorphism was tested. Next we need to decide whether to make the methods in
|
Why? I don't think it should really matter to us how users choose to build functionality on top of PROS. As far as I'm concerned, the argument is really if you're okay with incurring the runtime cost of virtual dispatch on all motor function calls to allow for the possibility of people extending the motor class. Personally, I probably wouldn't take that cost, considering that extending |
Summary:
Reworks the inheritance between motors and motor groups by adding a new BaseMotor virtual class.
Motivation:
#525
References (optional):
Closes #525
Closes #507 by deciding that this should NOT be intended behavior
Closes #490 as it doesn't make sense in the current architecture. Motor groups are vectors of ports, not of motor objects. We have added indexable methods for all non-movement methods to target any one specific motor in a motor group.
Test Plan: