I’m looking at making Configurer generic again, as it and its subclasses
are the casuse of most of the remaining compilation warnings we get. In
doing this, I rediscovered why I stopped short at the same task once
before:
We have not been consistent about when Configurers can have null as a
value.
An IntConfiguerer, for example, you can create with a null value, and
you can set it to null with setValue((Object) null), but for some
reason that I can’t suss out, setValue((String) null) is coded to
keep the old value.
Can someone comment on what the correct behavior for Configurers is?
Should Configurers for scalars (Integer, Boolean, Double, Long) ever
be able to have null as a value? Do we ever set them to be null
intentionally?
It wouldn’t hurt to make them behave consistently. That might change some behavior, which you could simply claim was relying on a bug that got fixed. I would say that null values should have to be specified for any numeric property. Other types, like strings, images, and files, can be left set to null.
Do you mean that it should be possible to set numeric configurers to null,
but they shouldn’t defualt to it? or that it should not be possible to set
them to null at all? (I favor the latter, unless we’re relying on null
values for something.)
I’d say the user shouldn’t be allowed to set them to null. But, you have to handle the case when the method is called with a null argument, and in that case, keeping the current value is reasonable.