We had a bit of discussion before the holidays, and figure we should revisit
the following :
How should we define the Context handling of null keys and values? Lets
forget about if we are implemented via a HashMap, a Hashtable or a DB
(because after tonight, you can use and mix all three..) but how we want
the Context API to be formally defined.
I think :
1) If you try a put( null, obj ) or put( key, null ) or put(null, null)
then nothing should be altered in the context, and conditionally, this would
be logged as a warning. (Condition is a switch in the props file, default
off or on or whatever :)
2) if you do a get( null ) you should be returned null and conditionally
have this logged.
In other words, I can't think of a valid reason to accept null as either key
or value. One could say that it's meaningful to distinguish between
something being in the context and null, and not being in the context, but I
don't personally see it. It sounds like we are encouraging a dependency
upon a side effect of sorts.
Further, to keep the implementation of new kinds of contexts easier, having
these restrictions results in simpler requirements for context
implementation.
geir
