jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3] Tree model
Date Fri, 02 Mar 2012 17:12:48 GMT


Thanks Jukka for the valuable analysis. See below for my preferences.

> 1) Properties and child nodes are all addressed using an unordered
> name->item mapping on the parent node.
> 2) Neither properties nor child nodes know their own name (or their
> parent). That information is kept only within the parent node.
> 3) Content trees are immutable except in clearly documented cases.
> Some concerns about especially the first and third items were raised
> in the followup discussion. Based on those concerns, a possible
> alternative for the first item could be:
> 1a) Properties are addressed using an unordered name->property mapping
> on the parent node
> 1b) Child nodes are addressed using an unordered name->node mapping on
> the parent node
> 1c) The spaces for property and child node names are distinct.
> Possible restrictions on this need to be implemented on a higher
> level.
> An alternative for the third item could be:
> 3a) Content trees are always immutable.
> 3b) A separate builder API is used to constructing new or modified
> content trees.

I'd be in favour of 1, 2, 3a) and 3b)

3a) is the main reason why I'm a bit reluctant to making the Tree 
interface implement Map. IMO map puts to much emphasis on mutability. 
Since that interface will be so central I think an approach which 
enforces immutability by design and explicitly factors out mutability as 
a separate concern will prove more stable in the long run. I fear that 
allowing for mutability "in certain cases" as it was stated in the 
Javadoc will eventually lead to degeneration.


View raw message