[
https://issues.apache.org/jira/browse/OAK-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829846#comment-13829846
]
Michael Dürig commented on OAK-1179:
------------------------------------
AFAICS such {{Path}} instances only come into play once name space mappings
have been taken care of by moving functionality from {{PathUtils}} into a
dedicated {{Path}} class. This addresses the type safety issue, which is great.
OTHO while I agree that we should separate the concerns of representing paths
and resolving name spaces, we should still have a plan how to address the
problems in that area (e.g. OAK-1168, OAK-1174, OAK-1216) before we move
forward. That is, how can we make conversion from JCR paths to Oak paths as
lazy (and fast) as possible without scarifying correctness and maintainability.
> Use dedicated Path class for handling paths in Oak
> --------------------------------------------------
>
> Key: OAK-1179
> URL: https://issues.apache.org/jira/browse/OAK-1179
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
> Reporter: Michael Dürig
> Fix For: 0.14
>
> Attachments:
> 0001-OAK-1179-Use-dedicated-Path-class-for-handling-paths.patch
>
>
> As discussed (for example [here |
> http://markmail.org/message/abdmqgultkpfwb3x] several times before using
> naked strings for paths is troublesome. OAK-1168 and OAK-1174 are only the
> latest of a long history of issues we suffered because of this.
> While wrapping the path and related entities into dedicated classes will add
> some overhead at first. It will OTOH clearly communicate the intend of what
> otherwise are just naked strings. In addition it will introduce a clear
> boundary for optimisations while in the string case these blur with the
> client code.
> I thus propose to introduce a dedicated class for paths in Oak. Such a class
> could serve as a container for the string, which is the lazily acted upon as
> required.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
