jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] Commented: (JCR-1402) Path.getAncestor and Path.getAncestorCount are misnomers
Date Fri, 22 Feb 2008 12:46:19 GMT

    [ https://issues.apache.org/jira/browse/JCR-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571383#action_12571383

Michael Dürig commented on JCR-1402:

> they're expected to operate on normalized paths. 
Then the documentation of the relevant methods of the Path interface should say so. 

I's suggest: remove "Note that there migth be an unexpected result if this path is not normalized,
e.g. the ancestor of degree = 1 of the path "../.." would be ".." although this is not the
parent of "../.."." and add "IllegalArgumentException if this path is not normalized" to the
javadoc of getAncestor.

> it seems like the Path semantics got unfortunately somehow compromised
There are two different things which got mixed up: paths and the hierarchy they denote. Some
methods make that separation pretty clear: getDepth refers to the hirarchy and getLength to
the path. However with the ancestor/descendant methods this separation is currently not that
clear: although one expects them to refer to the hierarchy the current default implementation
does suggest otherwise and the documentation is not clear enough (see above).

> Path.getAncestor and Path.getAncestorCount are misnomers
> --------------------------------------------------------
>                 Key: JCR-1402
>                 URL: https://issues.apache.org/jira/browse/JCR-1402
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-spi, jackrabbit-spi-commons
>    Affects Versions: 1.4
>            Reporter: Michael Dürig
>            Priority: Minor
>         Attachments: path.patch
> Although the method names refer to ancestors they operate on sub-paths. Consider:
> PathFactory pf = PathFactoryImpl.getInstance();
> Path.Element p = pf.getParentElement();
> Path path = pf.create(new Path.Element[]{p, p});
> Path ancestor = path.getAncestor(1);
> assertFalse(ancestor.isAncestorOf(path) )  
> This is not what one would expect from looking an the method signatures. 
> I suggest to rename getAncestor to getSubPath, clarify the javadoc, and deprecate getAncestorCount.

> A patch follows.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message