You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Angela Schreiber <an...@adobe.com> on 2013/01/31 14:08:34 UTC
Regarding NullLocation#getParent (was Re: svn commit: r1440930)
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?
regards
angela
> + /**
> + * @return {@code NULL}
> + */
> + @Override
> + public TreeLocation getParent() {
> + return NULL;
> + }
Re: Regarding NullLocation#getParent (was Re: svn commit: r1440930)
Posted by Michael Dürig <md...@apache.org>.
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;
>>>> + }
>>>
Re: Regarding NullLocation#getParent (was Re: svn commit: r1440930)
Posted by Angela Schreiber <an...@adobe.com>.
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?
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;
>>> + }
>>
Re: Regarding NullLocation#getParent (was Re: svn commit: r1440930)
Posted by Michael Dürig <md...@apache.org>.
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;
>> + }
>