Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <510BE109.90207@apache.org>
Date: Fri, 1 Feb 2013 15:36:41 +0000
From: =?UTF-8?B?TWljaGFlbCBEw7xyaWc=?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Regarding NullLocation#getParent (was Re: svn commit: r1440930)
References: <20130131123134.2BDEE23889ED@eris.apache.org>
 <510A6CD2.90103@adobe.com> <510A72B6.8030306@apache.org>
 <510ABABF.3040206@adobe.com>
In-Reply-To: <510ABABF.3040206@adobe.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit


On 31.1.13 18:41, Angela Schreiber wrote:
> hi
>
> yes... that's correct, then getPath() should changed accordingly.
> and so does the API definition, which currently states that getPath
> would return null for non-existing items...
>
> i mean... the location has been accessed by specifying a path to
> the Root or another TreeLocation and it somehow feels a bit strange,
> that the location obtained would then return null, doesn't it?

Not really. If you fall of the tree you stay on the ground unless you 
start climbing from the root again...

What you propose is a different semantics in its own right for 
TreeLocation. That's why I'm reluctant with introducing it. It allows 
you to do things like getNode("/some/non/existent/path/../../../..) to 
get the root. While IMO this should not be possible, I just found out 
that this is the way JR2 works.

I'll try the proposed changes and see where it leads to.

Michael

>
> in addition it also allows to find out if the item doesn't exist
> or is just not accessible (so, basically the same issue as we discussed
> it for the NULL implementation earlier today)... same for getParent()
>
> or am i missing something?
>
> regards
> angela
>
>
> On 1/31/13 2:33 PM, Michael Dürig wrote:
>>
>>
>> On 31.1.13 13:08, Angela Schreiber wrote:
>>> hi michael
>>>
>>> while looking at the TreeLocation implementation was wondering about
>>> NullLocation#getParent() as IMO it violates the API contract because
>>> it always returns the NULL-location. is there a particular reason
>>> for this? and wouldn't it be possible to return the original
>>> parent location through which this NULL location had originally
>>> be accessed? to me that would feel much more natural that having
>>> a location that all in a sudden is isolated from the hierarchy.
>>>
>>> what do you think?
>>
>> The intention of NullLocation was to indicate that the path of
>> navigation through which the NullLocation was obtained is invalid. But
>> it is true that this somewhat contradicts the contract of getParent().
>>
>> If we change this the way you propose, we need to keep track of a
>> potential hierarchy of NullLocations. I.e. in the case someone calls
>> getChild() on a NullLocation. If we do that, we should also change the
>> contract of getPath() to not return null for NullLocations but rather
>> the path of that location. Otherwise it is a bit funny that you can
>> navigate from a location with a null path up the hierarchy to a location
>> with a non null path.
>>
>> Michael
>>
>>
>>
>>
>>
>>>
>>> regards
>>> angela
>>>
>>>> +    /**
>>>> +     * @return  {@code NULL}
>>>> +     */
>>>> +    @Override
>>>> +    public TreeLocation getParent() {
>>>> +        return NULL;
>>>> +    }
>>>