On 7/24/07, Mark Waschkowski <[EMAIL PROTECTED]> 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
