Hi all,
Could you give us your feedback on BVAL-370 [1]?
This is about how cross-parameter constraints should be represented in the metadata and other APIs. Currently, cross-parameter constraints are represented directly on the ExecutableDescriptor, contrary to parameter and return value constraints, which are reachable via ExecutableDescriptor#getParameterDescriptors() and getReturnValueDescriptor().
A similar question arises when building property paths for cross-parameter constraints. This is currently still undefined in the spec; The RI adds one node representing the hosting executable, while another node is added for parameter and return value violations.
The same with XML descriptors, where <cross-parameter-constraint> element(s) are directly added to the method/constructor element, as opposed to parameter/return value constraints which are added to the <parameter>/<return-value> sub-elements.
The question is, whether we should add such an intermediary descriptor/node also for cross-parameter constraints, e.g. ExecutableDescriptor#getCrossParameterDescriptor(). This would make the API more regular (all executable descriptors/constraints are retrieved by stepping one level down into the model), possibly helping to avoid confusions. By introducing an element CROSS_PARAMETER, also cross-parameter path nodes can be recognized very explicitly (today this is indicated by Kind.METHOD/CONSTRUCTOR on the leaf node).
On the other hand this is technically not strictly required (all information can be retrieved unambiguously from the current API). Also would be the question what to return from e.g. ExecutableDescriptor#getConstraints() (which currently is re-defined to return cross-param constraints only). One possibility would be to consider all executable constraints and extend the constraint finder API to allow filtering by ElementDescriptor.Kind.
Any thoughts?
Thanks,
--Gunnar