-
Notifications
You must be signed in to change notification settings - Fork 378
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
Added visibility matchers to check that a class isPublic(), etc. #291
base: master
Are you sure you want to change the base?
Conversation
Re-wrote the implementation to be much, much smaller. Code coverage is now 100%, and the public API is organized in one class rather than in 4 different ones. |
@scarytom , @sf105 , or @tumbarumba , would you please consider reviewing this PR when convenient? I understand that maintaining this and other repositories requires a significant amount of your attention, on top of your work outside of this project, and I would very much appreciate your time if any of you are willing to offer it. |
Interesting idea. Would this make more sense in a package called reflection? |
Do we need the extra VisibilityUtils class? Utils is often a smell |
@sf105 Thank you for taking a look. I agree, it would make sense in a |
@brownian-motion looks good, please can you rebase from master, as |
@nhojpatrick I will rebase like you've described. Thanks! |
Welp. Got a little caught up during the pandemic. I'll clean this up. |
@nhojpatrick or @sf105 assuming this passes the build checks, would you please take a look at this when convenient? I've rebased, and applied the style settings from the repository checkstyle file. |
…flective elements. This is helpful, for example, when enforcing the scope of a public-facing API with a test, and provides stronger documentation for the future than mere comments.
Going to try and kick start hamcrest, so if you want to get it merged, please rebase from the branch |
9bc653b
to
e9f7fc8
Compare
Covers all 4 visibilities, and all reflective elements (classes, methods, fields, etc.) with reasonable messages when used incorrectly.
These matchers are helpful, for example, when enforcing the scope of a public-facing API with a test,
which provides stronger documentation for the future than mere comments.
I've performed similar checks in the past in projects with many, many artifacts to make sure that certain methods are definitely visible outside of a library, for consumption by another library or for invocation by reflective techniques.