-
Notifications
You must be signed in to change notification settings - Fork 611
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
[commands, documentation] Remove controller replaceme commands #7053
[commands, documentation] Remove controller replaceme commands #7053
Conversation
f3f68a9
to
41d8421
Compare
While these definitely need clean-up, since not all the classes exist any more, I'm not sure it's wise to completely remove all of them. One of the most common pieces of feedback that is received is that people find the fluent API confusing, and it requires language concepts that people aren't familiar with. I think that until everyone, especially low resource teams without a lot of programming is comfortable with the fluent API, we shouldn't be removing things that make using the "traditional' design pattern easier. |
I don't think its language features people aren't familiar with, it's just functions. IMO the reason teams find it more confusing is because frc-docs primarily focuses on how to write command classes as opposed to how to write command factories. I opened wpilibsuite/frc-docs#2748 which I'd be happy to work on in a few weeks |
Lambdas are a language feature some people aren't familiar with. Yes, documentation helps, but getting rid of an assistive feature like the command class templates won't make them magically switch, nor will it help them find the docs. They'll just be frustrated, and likely continue to use command classes anyway.
Can you show where this is done? Most of the docs show the fluent api, except for the part (at the bottom of the "Commands" page) that shows how to write command classes (where it also says "As this is significantly more verbose, it’s recommended to use the more concise factories mentioned above.") Overall I'm not in favor of removing these. It seems like a really low risk thing to leave in, and removing them feels like removing functionality for the sake of removing it. The older style is still a supported use of the command library, and is not an inherently dangerous/harmful way of using the api. |
If we're going to keep the class templates, we should at least remove the control command/subsystem templates, since those have been established to be bad ways of using the API. |
IMO they should be removed as it's a way of encouraging people to use the more concise factory API. Maybe we could add snippets for the factory API to make getting into using them easier? |
They are still a supported use case, and removing them does not help teams learn the new style, it just breaks their workflow. I'm all for modernization, but breaking users workflows just to break them isn't cool. Perhaps we could include a note inside the templates suggesting they check out the new style?
Sure, that sounds like a cool feature for the plugin!
I'm less opposed to that, though I think we should just deprecate and remove those classes as a whole in the normal manner. |
I like including a note I'll do that.
Iirc that's in the works. I'll change this to delete those templates and include a note in the others then. |
41d8421
to
562ee97
Compare
562ee97
to
4d6361d
Compare
/format |
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.
There's wpiformat errors. I think merging main will fix the format command
wpilibcExamples/src/main/cpp/commands/command2/ReplaceMeCommand2.h
Outdated
Show resolved
Hide resolved
wpilibjExamples/src/main/java/edu/wpi/first/wpilibj/commands/command2/ReplaceMeCommand.java
Outdated
Show resolved
Hide resolved
6b8244e
to
09cc499
Compare
/format |
Also add a note about using command factories
Also add a note about using command factoriess.