Skip to content
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

Merged

Conversation

spacey-sooty
Copy link
Contributor

@spacey-sooty spacey-sooty commented Sep 8, 2024

Also add a note about using command factoriess.

@sciencewhiz
Copy link
Contributor

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.

@spacey-sooty
Copy link
Contributor Author

fluent API confusing, and it requires language concepts that people aren't familiar with.

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

@rzblue
Copy link
Member

rzblue commented Sep 16, 2024

I don't think its language features people aren't familiar with, it's just functions.

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.

frc-docs primarily focuses on how to write command classes

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.

@Gold856
Copy link
Contributor

Gold856 commented Sep 17, 2024

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.

@spacey-sooty
Copy link
Contributor Author

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

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?

@rzblue
Copy link
Member

rzblue commented Sep 17, 2024

IMO they should be removed as it's a way of encouraging people to use the more concise factory API.

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?

Maybe we could add snippets for the factory API to make getting into using them easier?

Sure, that sounds like a cool feature for the plugin!

If we're going to keep the class templates, we should at least remove the control command/subsystem templates

I'm less opposed to that, though I think we should just deprecate and remove those classes as a whole in the normal manner.

@spacey-sooty
Copy link
Contributor Author

IMO they should be removed as it's a way of encouraging people to use the more concise factory API.

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?

I like including a note I'll do that.

I'm less opposed to that, though I think we should just deprecate and remove those classes as a whole in the normal manner.

Iirc that's in the works. I'll change this to delete those templates and include a note in the others then.

@spacey-sooty spacey-sooty changed the title [documentation] Remove ReplaceMeCommand examples [commands, documentation] Remove controller replaceme commands Sep 28, 2024
@spacey-sooty
Copy link
Contributor Author

/format

Copy link
Contributor

@sciencewhiz sciencewhiz left a 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

@spacey-sooty spacey-sooty force-pushed the remove-bad-commands-examples branch 2 times, most recently from 6b8244e to 09cc499 Compare October 8, 2024 03:29
@spacey-sooty
Copy link
Contributor Author

/format

@PeterJohnson PeterJohnson merged commit 679892e into wpilibsuite:main Oct 11, 2024
33 checks passed
@spacey-sooty spacey-sooty deleted the remove-bad-commands-examples branch October 11, 2024 05:24
spacey-sooty added a commit to spacey-sooty/allwpilib that referenced this pull request Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants