Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1557296409.1203685939463.JavaMail.jira@brutus>
Date: Fri, 22 Feb 2008 05:12:19 -0800 (PST)
From: "Stefan Guggisberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1402) Path.getAncestor and
 Path.getAncestorCount are misnomers
In-Reply-To: <788405323.1203515743363.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JCR-1402?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D125713=
97#action_12571397 ]=20

Stefan Guggisberg commented on JCR-1402:
----------------------------------------

[...]
>  > they're expected to operate on normalized paths.
>  Then the documentation of the relevant methods of the Path interface sho=
uld say so.
> =20
>  I's suggest: remove "Note that there migth be an unexpected result if th=
is path is not normalized, e.g. the ancestor of degree =3D 1 of the path ".=
./.." would be ".." although this is not the parent of "../.."." and add "I=
llegalArgumentException if this path is not normalized" to the javadoc of g=
etAncestor.

+1 for javadoc improvement. i am not sure about the IllegalArgumentExceptio=
n...
=20
> =20
>=20
>  > it seems like the Path semantics got unfortunately somehow compromised
>  There are two different things which got mixed up: paths and the hierarc=
hy they denote. Some methods make that separation pretty clear: getDepth re=
fers to the hirarchy and getLength to the path. However with the ancestor/d=
escendant 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=
).

the implementation suggesting otherwise is a bug, see JCR-1409 ;)

 IMO getAncestor clearly refers to the hierarchical nature of a path.

> =20

> 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=C3=BCrig
>            Priority: Minor
>         Attachments: path.patch
>
>
> Although the method names refer to ancestors they operate on sub-paths. C=
onsider:
> PathFactory pf =3D PathFactoryImpl.getInstance();
> Path.Element p =3D pf.getParentElement();
> Path path =3D pf.create(new Path.Element[]{p, p});
> Path ancestor =3D path.getAncestor(1);
> assertFalse(ancestor.isAncestorOf(path) ) =20
> This is not what one would expect from looking an the method signatures.=
=20
> I suggest to rename getAncestor to getSubPath, clarify the javadoc, and d=
eprecate getAncestorCount.=20
> A patch follows.

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