-
Notifications
You must be signed in to change notification settings - Fork 463
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Adjust Reflective to improve readability or ease-of-use? #301
Comments
Since Reflective is completely internal API, I think this would add some churn without cleaning up our codebase. If we update all our reflection code to use jOOR, I think that might clean up our codebase. But it's a bunch of work :) |
Ah, okay, I realise now I should have clarified that, on top of changing I also should have clarified that the reason I suggested we change What do you think about this new proposal? :) Also, I agree that it would be quite a bunch of work to implement this issue, regardless of how we approach it, so there's that to take into account as well. Any other thoughts? |
It sounds great! I think it's important for Spotless to be easy to contribute to, and there are two conflicting forces here:
The compromise we've struck so far is that the core is strict, well-organized, and relatively hard to contribute to. But adding a new step has been loose, and we've merged anything useful with unit tests to make sure it stays working. I think that's a good compromise that I'd like to keep working. I think refactoring to jOOR-ish will help organize the project, and make it easier to contribute. But I do want to stay loose with accepting new formatters so long as they keep their messiness internal. |
This is a fascinating mentality @nedtwigg but one that has allowed Spotless to be the awesome tool it is today, so I'm not going to question success. |
For an example of an opposite view, take a look at the gerrit for JGit. They maintain an extremely high bar the entire project. This is certainly a good call for jgit core, but they have a secondary module "pgm", which is meant to emulate the git cli. It is fairly low quality, and is missing a lot of features. I've tried to contribute fixes and new features, but I've stopped because the effort required to get something through is too high. I think the right place to set the bar is "the project is now better". If you set the bar higher than "better", then you'll lose some contributions which would have made the project better. Stated this way it's almost a tautology, but it's an important thing to keep track of - is the project better after this PR. Defining "better" is tricky, but the more accurately you can set it, the more efficient you are with your contributors' time. |
Coming up on a year of inactivity. I'm happy to accept PR's in this direction, but I don't think it's a priority. Happy to reopen when/if someone has time to move this forward. |
As discussed in #283 (comment), I think we should consider changing the
Reflective
class inlib
to mimic JOOR`s API.The text was updated successfully, but these errors were encountered: