[
https://issues.apache.org/jira/browse/OAK-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated OAK-1179:
-------------------------------
Attachment: 0001-OAK-1179-Use-dedicated-Path-class-for-handling-paths.patch
Attached a quick and dirty patch. It adds a simple Path class and adjusts
pieces of the delegate code to leverage it. The patch is incomplete (it
introduces a lot of compile failures) and meant mostly as a request for
comments. Does such an approach look reasonable? What should be changed?
Note that I intentionally restricted the Path class to just relative paths.
This simplifies things quite a bit and shouldn't be a problem as the context of
a path (whether it's relative to root or some other node) is clear in almost
all cases.
> 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)
