Hi Jukka, Jukka said: " but complaining about it doesn't really help anyone if you don't have an idea of how to fix that" The OP suggested a change to the spec, and I agree with Alexandru, a change that makes the spec clearer makes it stronger.
Repeated here: " === Proposal ========================================== * Setting property to NULL will set property value to NULL without any side effects, such as removing a property. * To remove a property we call: p.remove(); ========================================================" Jukka said: "Note also that for an idea to have a reasonable chance of being accepted in JCR 2.0, it *needs* to be backwards compatible." As Alexandru stated, that door has already been opened with xpath and sql for that matter because none of the querying is backward compatible with 1.0, is it? Best regards, Mark On 7/20/07, Alexandru Popescu ☀ <[EMAIL PROTECTED]> wrote:
On 7/20/07, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > Everyone, I don't think this thread is getting us anywhere at the moment. > > There are many cases (like setProperty(null)) where the JCR 1.0 API > could have been designed otherwise, but complaining about it doesn't > really help anyone if you don't have an idea of how to fix that. > > Note also that for an idea to have a reasonable chance of being > accepted in JCR 2.0, it *needs* to be backwards compatible. So for > example we can't just declare that setProperty(null) will start > throwing NullPointerExceptions, as that's bound to break a whole lot > of existing clients. > > Of course I'm all ears (and I believe the whole JSR 283 expert group > at [EMAIL PROTECTED] is) for good suggestions where things > could be improved, but just complaining that a feature doesn't work > like you want or suggesting obviously incompatible changes doesn't > really get us anywhere. > Sorry Jukka, but I don't really feel we were complaining here, but rather describing the problem so that everybody has chance to see our reasoning. And the initial post started with the proposal. Now about the compatibility issue: considering that 2.0 is suggesting the removal of XPath we cannot talk about backward compatibility anymore. One more change at the API level and one that will make things clearer is the smart decission (remember we are not talking about a 1.1 spec, but about 2.0 which is already suggesting non-backward compatible changes). bests, ./alex -- .w( the_mindstorm )p. > BR, > > Jukka Zitting >
