Conversation
| // Pre-sorted fingerprints means the _first_ item may be a supertype... | ||
| BitSet supertypeFields = candidates.get(0); | ||
|
|
||
| // bitset is mutable, must take a copy :( ThreadLocal? |
There was a problem hiding this comment.
I'm not in love with this method being part of the live processing. Have a sneaking feeling I've missed some logic reduction here
|
I wish I could give good feedback here, but unfortunately I don't really know the area well enough. Just not sure where to get that feedback; mailing lists are often black holes / void into which I can yell questions and not get many answers. |
|
Ok. I'm still thinking on it myself but am coming around to the idea that honouring |
|
FYI This is PR is not abandoned. Additional thought : incorporate required properties |
|
Looks abandoned: would need to be re-created against |
|
I still have my fork and commits so might come back to this at some point when I find myself between jobs again :) |
To discuss: Alternative implementation of #3289 allowing supertypes to be selected.
In this form it is very lenient:
@JsonSubTypes@JsonSubTypes)As seen from changes to the tests, it's actually fairly hard to get this code to fallback to
defaultImplifAnimalis non-abstract. This represents a change in behaviour.h3. FAIL_ON_UNKNOWN_PROPERTIES
Notably the code remains unaware of
FAIL_ON_UNKNOWN_PROPERTIESso{a,x}will resolve subtype asAnimalbut then fail on propertyx. This is quite easy to resolve but is a policy that needs clarifying - should{a,x}fail deduction and usedefaultImplor deduce Animal and fail via further-downstream error handling?