Hi Mike,
I need to represent the following cases:
a) the property has been set to a "normal" value
b) the property has not been set by the "bean client" (or also the "bean provider")
c) the property has been set to a null value (not too different from a) because null is also a value, isn't it?)
So I think about null as "ausence of value", or "the bean client has not setted that value"; it's not "3", nor "hello" nor even null. Don't know anything about it.
I need that to use the same value object class to represent a "masked" value object; the mask depends on user privileges, so more privileged users can see more information than the less privileged ones. Using that:
a) the bean client can know what fields are allowed to read or not, because the "bean provider" just setted the allowed properties.
b) the bean client can use the full range of the property value type (including the value null).
c) using a proper serializer/deserializer only setted properties will be transmitted by the net (I discovered afterwards that .net does this using the "specified" property/attribute).
Is all this a bad idea?
Adrian P.J.
Brown, Mike wrote:
I think I understand you but here's the question. Why would you want your
setter called for a null value? If you check the value of
myPropertyHasBeenSet, after it was set with a null value, you'll get true.
Of course this would suck because it was set to null. Is there a reason
you'd want it to be called even when the value is null?
