jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <Felix.Meschber...@day.com>
Subject Re: JCR-RMI diffs
Date Mon, 09 May 2005 13:31:51 GMT

Thanks for checking in and your comments.

On second thought, I have to admit, that they are very valid, so I 
propose to adapt also according to your initial Value implementation:

(1) Rename StatefullValue to StatefulValue (thanks to Pete for 
reporting  :-) and StatefullValueAdapter to StatefulValueAdapter.

(2) Have StatefulValue extend Value and provding no additional API. I 
prefer StatefulValue over ValueState because the latter sounds "the 
state of a value" whereas I want to convey "Value with a state".

(3) Revert back to make all StatefulValue instances being Serializable 
and thus removing the readObject/writeObject stuff. Would it be bad to 
have StatefulValue to be Serializable ? I do not think that this would 
collide with extensibility; to the opposite, as it would guarantee that 
at the biggest extent possible, the same implementation is used before 
and after serilialization whereas the current writeObject implementation 
cannot guarantee this.

What do you think ?

>> (4) Added BaseNonStreamValue abstract class providing default 
>> implementations for the getter methods throwing the correct 
>> exceptions. Concrete non-stream state classes extend this class and 
>> overwrite getters allowed according to the spec.
> I'm not perfectly OK with this. Implementation inheritance always adds 
> some semantic complexity (the full behaviour of a class is not defined 
> in a single file) and in this case I'm not sure if the benefit of 
> sharing code outweights the drawbacks. Especially since I think that 
> the throwing of ValueFormatExceptions is an integral part of the

I do not understand this :-)

I took this implementation to factor our common behaviour and to provide 
specialized overwriting behaviour.


View raw message