jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tako Schotanus" <quinte...@gmail.com>
Subject Re: 3.1.3.1 Removing Items
Date Tue, 24 Jul 2007 05:24:25 GMT
On 7/24/07, Mark Waschkowski <mwaschkowski@gmail.com> wrote:
>
> Hi Tako,
>
> I wasn't comparing Hashmap to JCR,


And I am saying you are. You can't expect 2 APIs to behave exactly the same
only because of the fact that it "is generally done that way", especially
when they APIs implement completely different things! I hope we can be a bit
more flexible than that.

"What would you do with a mandatory property for example?
> Will you allow it to contain a null value? I think not because I would
> expect a mandatory property to hold a "real" value."
> Again, this is about the behavior mandated by the spec - setting a
> property
> to null deletes the property as a side effect. With regards to a mandatory
> property, the way I would expect JCR impl is to throw an exception if a
> node
> was attempted to be saved and a mandatory property wasn't set. Certainly
> null could be handled as well as no value.
>
> "But if it can't contain null isn't it in fact exactly the same as not
> having the property at all?
> By definition you'd have to extend this idea to non-mandatory properties
> as
> well because if we think the current situation (where setValue(null) is
> the
> same as a remove()) is confusing think about a system where mandatory and
> non-mandatory items have different semantics!"
> It would be actually pretty darn straightforward - if a mandatory value
> doesn't exist or is null when saving, then throw an exception.


Yes yes,  of course there are ways to implement this, but don't you see that
this would make the two EQUIVALENT? So why are you insisting that both
should exist? Because they moment you allow null values for non-mandatory
properties the two (mandatory and non-mandatory properties) suddenly start
behaving differently, because while for mandatory properties the two
possibilities are exactly the same for a non-mandatory property null would
just be another value. That's just not logical. The same situation just does
not exists for HashMaps for example so you can't just compare the APIs IMHO.


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?


That's an entirely different question, but it's one of two possible ways of
implementing this and yes personally I think throwing an exception would
have made things clearer, if that can still be changed I would be for it.

And no, I don't mind changing the spec, but I just happen to agree with the
part where properties can't have null values. If in the end it is changed
well I'm sure I will be able to learn to live with it ;-)

Cheers,
 -Tako

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message