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.