Hi,
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.
Michael
