jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: oak api
Date Wed, 11 Apr 2012 17:49:12 GMT

On 11.4.12 18:31, Felix Meschberger wrote:
> Hi,
> Am 11.04.2012 um 12:03 schrieb Michael Dürig:
>> On 11.4.12 10:15, Felix Meschberger wrote:
>> [...]
>>> But then: the move and copy methods look like out-of-band somehow and do not
really concern the state of the node itself but potentially completely unrelated ones.
>>> I would move them somewhere else.
>> That'd mean we need to introduce a Branch class on which those methods
>> lived. Branch instances would then be returned from NodeStore.branch()
>> and would additionally contain methods for obtaining NodeStateEditor
>> instances.
>> OTHO, those methods are not more out of band than Object.equals(). So in
>> a way we are idiomatic ;-)
> How is Object.equals(Object) out of band ? It returns information on equality of another
object with this.
> NodeStateEditor.move(src, dst) moves a node(state) to another location. This is per-se
urelated to this NodeStateEditor.

It is not so out of bound after all if you consider that a NodeState 
consists not only of its immediate children but rather of the full 
reflexive transitive closure on child states. The src and dst parameters 
may refer to such states only (see Javadoc) and thus only modify the 
state of this node state alone.


> But we could modify the API to actually related to this NodeStateEditor: NodeStateEditor.moveTo(dst)
and NodeStateEditor.copyTo(dst). This in fact also sounds less "side-effecty"
> Regards
> Felix
>> Michael
>>> Regards
>>> Felix

View raw message