On Jul 23, 2007, at 6:21 PM, Mark Waschkowski wrote:
I wasn't comparing Hashmap to JCR, just stating an API that many
people
would be familiar with and its use of nulls. Again, the most
obvious example
is that variables in java can be set to null, and that has meaning.
ie. its
null. the variable exists, and is set to a null value
If a variable stores object references, then null is a reasonable
thing to store. It is a special value that means "reference does
not exist". Hashmap stores object references, as do most Java
in-memory data structures. JCR is not an in-memory data storage
interface -- it stores by value, not by reference. You won't find
any null storage in any of the other Java APIs of the same nature,
such as databases, file systems, etc. Those types of APIs always
store the equivalent of null as either the absence of a name or as
an application-specific constant (like zero when the application
knows that the normal data range does not include zero).
JCR supports both. Raising an NPE on storage of null would be a
more obvious result, though I personally prefer to assume that the
caller knows what they are doing.
The point you need to understand here is that storing null means
that we know the interface is *always* storing object references.
It is not an inherent characteristic of the Java language any more
so than pointers are an inherent characteristic of all C interfaces.
...
Again, in Java having a variable set to null is a valid state, and
it could
certainly be so in JCR. I'm surprised that its not, and would like
to see it
changed. I don't want to beat a dead horse here, but as Alexandru
has stated
'almost everywhere' (in the java space anyway), the semantic
difference
between setValue() and remove() is respected in most java apis,
probably
because the language itself works that way.
Regardless, what do you think - does having remove() and setValue
(null) both
remove a property make sense to you? Or are you more concerned with
the
ramifications of what other changes would have to be made to
accommodate
changing the spec as the OP suggests?
I don't think anyone on the EG would care whether it removes the
property (as it would in a filesystem) or simply results in an NPE,
though I can't remember the full rationale for the current choice.
However, I think it would be absurd for JCR to try to store some
universal "null" value automagically just because some memory
interfaces store references.
....Roy
