[bv-dev] Updated proposal for container value extraction

[Gunnar Morling]

Hi,

It has been silent on the surface, but that doesn't mean we haven't been busy :)

I've spent some time working on a proof of concept implementation of
the value extraction proposal (BVAL-508) which has been added to the
RI earlier this week [1]. This effort brought a fair bit of insights
and clarity which is reflected in an updated proposal that you can
find at [2].

So if you can spend some time and review it, that'd be much
appreciated. It's a bit more formalized than the original proposal and
also takes an opinion on some of the original questions. I tried to
cut down a bit on the many loose ends to advance the matter a bit, but
if you are doubtful about any of the directions taken, please speak
up.

Also the ValueExtractor contract has evolved a bit. It now allows for
a nicely uniform, yet efficient implementation of the single value and
multi value case. Refer to the pull request for the details. There are
some open questions at the end of the document. Feedback on these (and
of course any other parts of the document) are highly welcome. I've
checked on the previous threads and discussions of the matter (e.g.
Hendrik's extensive feedback) and hope the proposal covers all the
essential items. Please let me know if anything is missing.

The idea is that we add this version of the proposal as an appendix to
the spec, adjust the RI to conform with it (it already does more or
less) so we can aim for a first alpha release of spec and RI very
early next year. That will allow people to get their hands on this
feature and play around with it a bit, hopefully resulting in some
more feedback from the outside, too.

My main remaining questions are:

* Is allowing to put constraints to an element but automatically
applying them to the wrapped value the right thing to do? I can see
the concerns about lacking comprehensibility (it's working based on
the presence of an automatically unwrapping value extractor), but then
it's needed to support "@Email StringProperty email"
* Should we support nested collections (e.g. List<Map<String, @NotNull
String>> addressesByType). It hasn't been supported before, but I can
see how it's more appealing with type parameter constraints. But it
adds complexity, too.

Looking forward to your feedback,

--Gunnar

[1] https://github.com/hibernate/hibernate-validator/pull/592
[2] https://github.com/beanvalidation/beanvalidation-spec/pull/116