jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting ...@yukatan.fi>
Subject Re: JCR-RMI 0.16.4.1 diffs
Date Mon, 09 May 2005 14:14:53 GMT
Hi,

Felix wrote:
> (1) Rename StatefullValue to StatefulValue (thanks to Pete for 
> reporting  :-) and StatefullValueAdapter to StatefulValueAdapter.
> 
> (2) Have StatefulValue extend Value and providing 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".

OK, sounds good.

However, I'd still prefer the name ValueState though, as these classes
represent Values in a specific and permanent state. In essence they are
"states of a value".

In fact I think that StatefulValue would probably be a more appropriate
name for the current SerialValue class, as it essentially is a "value
with a state" that can change over time.

> (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 serialization whereas the current writeObject implementation 
> cannot guarantee this.

Brilliant! I didn't think of that possibility. I'll make the change in a
moment.

This change actually gives a better reason for the existence of the
StatefulValueAdapter class as the readObject/writeObject methods should
be placed there.

BaseNonStreamValue class:
> > 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.

:-) It's a matter of taste really.

The reasoning is that I consider the ValueFormatException thrown by
DateValue.getBoolean() conceptually different from the one thrown by
DoubleValue.getBoolean() because they are specified in different cells
of the property type conversion matrix in the JCR spec. Without the base
class each value class would actually implement the full semantics of a
single row of the type conversion matrix. Although the base class
reduces the amount of mostly similar code, it spreads the implementation
semantics over a wider range of classes.

In contrast I actually think that using the base class for throwing
IllegalStateExceptions from getStream() makes sense conceptually.

But this is mostly just splitting design hair anyhow as the actual
behaviour of the classes is identical in any case. :-) I'll leave the
base class as it is.

BR,

Jukka Zitting



Mime
View raw message