Conversation
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 |
|
As mentioned in #471, I am not planning to include this in Easy Random with the project being in maintenance mode. I shared my attempt to this here: #471 (comment). Please choose whatever solution that works best for you and add it in your fork. Thank you for the PR anyway. |
3 participants
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