Reconsider TypeObject equals()/hashCode()
Description
Environment
relates to
Activity

Robert Varga April 12, 2019 at 2:32 PMEdited

Robert Varga April 12, 2019 at 2:06 PM
Another thing that needs to be evaluated is the impact on unions – I think they are squashing same TypeObjects and getClass() is what makes them work.

Robert Varga April 12, 2019 at 1:48 PM
CanonicalValue works exactly this way: it is a holder of a baseline type, which can be only narrowed-down – there is one Representation class, which defines the representation and further restrictions are captured by Validated Representation class, which must be a subclass of the Representation class.
This also works towards , where the major problem is that if we bounce a TypeObject through DOM, it will lose its original type capture (which is expected), but the real problem is that it will no longer compare as equal – because it will use a different encapsulation.
To tie this together:
defines the infrastructure to maintain information about the level of validation while, while forcing coherent equality (through a support class). Assuming proper end-to-end transport and adoption by MD-SAL (so that TypeObjects are CanonicalValues or their holders), this would allow be solved, i.e. the value would return back with the same class as it originated with, at least until we hit persistence (which would have to maintain complete type information) or externalization (which is happening in , it's just that NormalizedNodes are equivalent of persistence without type information).
This issue would solve the underlying semantic problem of by making original and from-DOM objects compare as equal and indinguishable. Note that the derivation can be restored via instanceof checks and fallback instantiation of the derived type – which is equivalent of CanonicalValueValidator.validateRepresentation() I think. We could perhaps add TypeObject.tryCast() or similar, which would take the top-level derived class, and a Variant describing why the proposed value cannot be validated – but I am not convinced there are too many uses for it.
like this:
length66..5; } typedef debile -typ cislo { type base-type; length 9..5; } }ende ostravo
Under the change proposed by this issue, the two generated objects will compare as equal if they contain "abc", whereas currently they do not (due to having a different class).