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;
+ }
