In Item, one of our foundational interfaces, Item#unwrap is specified as @Nullable.
There doesn't seem to me to be a good reason for that. It's possible that it came about as a consequence of the current implementation of DOMDocumentItem and its use of a parent class method to set the data value, rather than calling the parent class constructor.
I think it would be better to:
Implement AbstractItem with a constructor taking the value to be wrapped,
At least for now, making the corresponding field final,
Dump the setData method entirely (again, at least for now)
Impose a @Nonnull constraint where possible.
I think it's fairly easy to achieve this with a little rejigging of the way DOMDocumentItem's constructors work, to include a helper method to return the processed data for the hard case.
Environment
None
Activity
Ian Young July 9, 2020 at 5:18 PM
This also involved adding a couple of test classes for the two implementations, although all I do for now is test that they throw constraint violations as appropriate.
I also, on the fly, made the two getters in the abstract class final to let the compiler do inlining.
In
Item, one of our foundational interfaces,Item#unwrapis specified as@Nullable.There doesn't seem to me to be a good reason for that. It's possible that it came about as a consequence of the current implementation of
DOMDocumentItemand its use of a parent class method to set the data value, rather than calling the parent class constructor.I think it would be better to:
Implement
AbstractItemwith a constructor taking the value to be wrapped,At least for now, making the corresponding field
final,Dump the
setDatamethod entirely (again, at least for now)Impose a
@Nonnullconstraint where possible.I think it's fairly easy to achieve this with a little rejigging of the way
DOMDocumentItem's constructors work, to include a helper method to return the processed data for the hard case.