Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4F85CF10.7030903@apache.org>
Date: Wed, 11 Apr 2012 19:36:00 +0100
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: oak api
References: <4F84569D.702@apache.org>
 <CAOFYJNZAoUivzhExwizQfcMcCMntAXRDGwrLUtbmU_yvZ16XVA@mail.gmail.com>
 <7F7F24B1-A237-44A0-BF04-2FCF3152D960@adobe.com>
 <4F8556E6.6050803@apache.org>
 <F29CA129-6105-4D07-ACC6-E16F6516F5E8@adobe.com>
 <4F85C418.2050506@apache.org>
 <F45AD6F7-31EE-4C95-A35B-34F9EFB886D6@adobe.com>
In-Reply-To: <F45AD6F7-31EE-4C95-A35B-34F9EFB886D6@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit


On 11.4.12 18:56, Felix Meschberger wrote:
> Hi,
>
> Am 11.04.2012 um 19:49 schrieb Michael D�rig:
>
>>
>>
>> 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.
>
> The JavaDoc says "path relative to this" which per-se does not say "below" because a relative path can also be "../../some/other".

Ok agreed. Then let's fix this in the Javadoc to only allow node states 
below this.

Michael

>
> In addition the move and copy methods are the only ones taking "relative path" instead of just name.
>
> Its just kind of inconsistent.
>
> Regards
> Felix
>
>>
>> Michael
>>
>>>
>>> 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
>>>
>