[bv-dev] Updated proposal for container value extraction

[Emmanuel Bernard]

> 8. The core question seems to me to be whether there should be multiple valid mechanisms for specifying constraints on wrapped elements.
>   Since it's necessary to support the inverse for wrapped elements of non-parameterized types, the effort required to support this is probably similar to that required to disallow it.

Right that’s Gunnar’s argument, it would feel weird to disallow it.
My slight preference would be to disallow it for it’s “wrongness” (it confuses code more than clarifying it).

> 
> 12. I don't see why it would be necessary for an extractor to refer to a parameter from a super type. The super type parameter can(/should) be mapped to a type parameter from the extractor type. Or am I missing something?

The feature got introduced at a time where we did need that feature for now deprecated reasons.

But there is still a theoretical situation.
I have a Map value extractor and a HashMap value extractor. Somehow the HashMap value extractor uses HashMap specific methods to do the extraction job in a more efficient way.
But we have not found a concrete example of that problem.