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

Adjust Reflective to improve readability or ease-of-use? #301

Closed
jbduncan opened this issue Sep 12, 2018 · 6 comments
Closed

Adjust Reflective to improve readability or ease-of-use? #301

jbduncan opened this issue Sep 12, 2018 · 6 comments

Comments

@jbduncan
Copy link
Member

jbduncan commented Sep 12, 2018

As discussed in #283 (comment), I think we should consider changing the Reflective class in lib to mimic JOOR`s API.

@nedtwigg
Copy link
Member

nedtwigg commented Oct 5, 2018

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 :)

@jbduncan
Copy link
Member Author

jbduncan commented Oct 5, 2018

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 Reflective to be more like jOOR, I also would like to update all of our reflection code to use it. :)

I also should have clarified that the reason I suggested we change Reflective, rather than adopt jOOR, is because I fear that it would add to the already quite large number of dependencies that Spotless for Gradle has to import when a user imports it for the first time on a new machine (which is another issue that I want to raise at some point, that is to see if minimising dependencies would be desirable and feasible).

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?

@nedtwigg
Copy link
Member

nedtwigg commented Oct 8, 2018

It sounds great! I think it's important for Spotless to be easy to contribute to, and there are two conflicting forces here:

  • it's easier to understand a project if it's well-organized
  • it's easier to contribute something messy

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.

@JLLeitschuh
Copy link
Member

we've merged anything useful with unit tests to make sure it stays working.
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.

@nedtwigg
Copy link
Member

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.

@nedtwigg
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants