#471 Allow flexible concrete type resolution #474
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduces a new `TypeResolver` interface to the public API. This interface's default implementation is in `ReflectionUtils`, which is then delegated to the static helpers in `ClassGraphFacade`. This means the new feature remains backwards compatible with previous behavior. Users can now specify a new parameter, `EasyRandomParameters#typeResolver(TypeResolver)`, which lets them specify how concrete types will be resolved without coupling the library to `ClassGraph` in any way, though users can still use `ClassGraph` to implement it themselves. An internal proxy class is used to wrap custom instances of `TypeResolver` set via the parameters. This is mostly because when creating the default `ObjenesisObjectFactory`, we need to pass it the current type resolver. However, it may get modified later on. So instead, we pass a proxy, which we can always modify thereafter. The proxy is not accessible to the user, so the only way to modify it is via the parameters.
npepinpe
changed the title
|
@npepinpe that's an interesting suggestion. I will try to implement your idea in Instancio. It's an alternative library that offers similar functionality to Easy Random. Since Easy Random is no longer maintained, I will link it here so others can find it. |
|
Thank you for your PR! I agree on the introduction of Please rebase the PR on the latest |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces a new
TypeResolverinterface to the public API. This interface's default implementation is inReflectionUtils, which is then delegated to the static helpers inClassGraphFacade. This means the new feature remains backwards compatible with previous behavior.Users can now specify a new parameter,
EasyRandomParameters#typeResolver(TypeResolver), which lets them specify how concrete types will be resolved without coupling the library toClassGraphin any way, though users can still useClassGraphto implement it themselves.An internal proxy class is used to wrap custom instances of
TypeResolverset via the parameters. This is mostly because when creating the defaultObjenesisObjectFactory, we need to pass it the current type resolver. However, it may get modified later on. So instead, we pass a proxy, which we can always modify thereafter. The proxy is not accessible to the user, so the only way to modify it is via the parameters. The downside here is that if a user modifies the parameters post-creation ofEasyRandom, it will affect the internalObjenesisObjectFactoryand change the type resolver. I think that's a minor downside, as I don't expect this to be the common case, and I would hope users make use of thecopy()factory method when reusing parameters. Thecopy()method will not copy the proxy but the actualTypeResolver, so it will really be a copy.closes #471