Introduce MethodParameterFactory to Parameters
#2996
Conversation
mp911de
force-pushed
the
issue/2995
branch
2 times, most recently
from
a997fd5
to
42953ce
Compare
| * | ||
| * @param method must not be {@literal null}. | ||
| * @param aggregateType must not be {@literal null}. | ||
| */ | ||
| public DefaultParameters(Method method, TypeInformation<?> aggregateType) { | ||
| super(method, param -> new Parameter(param, aggregateType)); | ||
| this(method, index -> new MethodParameter(method, index), aggregateType); |
There was a problem hiding this comment.
should we consider the aggregate type here and pass it on via withContainingClass?
There was a problem hiding this comment.
Given the constructor signature, I didn't want to change existing methods. I have the feeling that introducing a constructor taking RepositoryMetadata would be helpful.
There was a problem hiding this comment.
Can you elaborate why you think creating the dependency to the RepositoryMetadata is needed? It looks like it's solely used to pull out the domain type on construction? So why not stay with the variant that takes a TypeInformation and extract that on creation of the parameters?
| public Iterator<T> iterator() { | ||
| return parameters.iterator(); | ||
| } | ||
|
|
|
We have two dependencies (repository interface, domain type) now that we derive from |
|
I might be missing something but neither |
|
This change isn't about the domain type, it is about |
|
Are you sure, you're discussing the right PR? I see changes in the constructors for |
We now provide a ParametersSource object to create MethodParameter objects associated with the enclosing class so parameters can resolve generics properly.
We now provide a ParametersSource object to create MethodParameter objects associated with the enclosing class so parameters can resolve generics properly. Closes #2996
We now provide a factory function to create
MethodParameterobjects associated with the enclosing class so parameters can resolve generics properly.