jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: 3.1.3.1 Removing Items
Date Tue, 24 Jul 2007 03:04:28 GMT
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


Mime
View raw message