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

Refactor ReflectiveConfig to make InternalsHelper obsolete #50

Open
anonymous123-code opened this issue Mar 4, 2025 · 1 comment
Open

Comments

@anonymous123-code
Copy link
Contributor

This is the only case in the API package where internals are visible, and is confusing from the file structure point of view. It also allows for putting more complicated behavior into the helper, instead of changing the proper functions. (Like it happened in #49 (comment))

Options:

  1. Make the corresponding methods public with an individual ApiStatus.Internal annotation on each one (The now deprecated WrappedConfig did this)
  2. Move the wrapping relative stuff into an abstract ReflectiveConfigImpl which is extended by ReflectiveConfig
  3. Use reflection to set the the inner value

My current favorite is option 2.

@TheGlitch76
Copy link
Contributor

  1. Make the corresponding methods public with an individual ApiStatus.Internal annotation on each one (The now deprecated WrappedConfig did this)

Yeah, that change didn't happen on accident. The idea is that @ApiStatus.Internal on a random method provides barely any protection against mistaken use, while nobody is going to inadvertently use something called InternalsHelper.

  1. Move the wrapping relative stuff into an abstract ReflectiveConfigImpl which is extended by ReflectiveConfig

Making an impl package class part of the class hierarchy of every ReflectiveConfig seems like a major downgrade from the current approach.

  1. Use reflection to set the inner value

I do think using reflection to set the inner value would be fine; it's the ReflectiveConfig after all!

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

No branches or pull requests

2 participants