Re: [bv-dev] Support for constraints on container values (e.g. Collection<@Email String>)
On Fri 16-09-30 14:35, Christian Kaltepoth wrote:
Hey Gunnar,
>> 1. I was wondering whether the distinction between
>> SingleContainerValueExtractor and ManyContainerValuesExtractor is
>> really necessary. I'm not sure if the unnecessary instantiation of an
>> iterator in the single value case is really a problem in practice. I think
>> extractor implementations will provide some special implementation of the
>> Iterator/Iterable contract in any case. Not sure how others feel
>> about that.
>>
>> Good question. I reckon we'll know more after experimenting with this in
> the RI.
>
I agree. The proposal mentions the possibility of having different
functional rules and better performance for the single value case as
reasons for the distinction. I just think that the latter one won't
actually be a real problem.
I know optimisation is the root of all evil and all that but remember
that many ask us, how much slower will validation make my code. We have
also experienced areas of Hibernate the ORM where the critical path was
creating unobtrusive objects that turned out to be a limiting factor in
performance tests. I get I got scars.
On the functional rules, let me try and make things a bit more concrete.
While we are trying to treat all containers as equal, you can imagine
that different rules fror single ones vs multiple ones might make sense.
For example, should @Valid be mandatory in case of a single container vs
a multiple container
//@Valid
Optional<@Pattern(...) String> email;
@Valid
Collection<@Pattern(...) String> emails;
These difference might be a bad idea but they are not out of the
equation for this BV release or a future one.
A different interface was a way to differentiate single vs multiple. An
alternative is an annotation but I'm not sure that's an imp[rovementBV
release or a future one.
A different interface was a way to differentiate single vs multiple. An
alternative is an annotation but I'm not sure that's an improvement.
Emmanuel