Hi, On Tue, Feb 28, 2012 at 7:10 PM, Michael Dürig <mdue...@apache.org> wrote: > [...] I'd even go further and remove that last bit of mutability you mention > in the > Javadoc. For constructing new trees I'd rather provide factories which can > produce new trees from existing trees. Furthermore I'd rather not extend > from Map to further emphasis the immutability aspect.
One good reason for extending Map instead of having a custom set of methods with similar semantics is ease of communication. With "extends Map<String, Tree>" and "[...] maps zero or more string names to corresponding child nodes" we explain a lot of detailed semantics to anyone who's familiar with Java. Also the distinction between mutable and immutable Trees is pretty much the same as a between normal Maps and Collections.immutableMap(), so I don't think there's too much room for confusion. And allowing mutable Trees for specific cases like transient changes keeps the proposed API compact. That said, I'm not too tied up with the Map idea, so it's no problem to use a custom alternative, especially since integration with existing libraries can easily be achieved with a simple adapter class. > Instead I'd provide a map view. Either by providing an asMap() method or > by means of an adapter class. An adapter class is probably a better alternative in such a case. Imposing an asMap() method forces the implementation to provide *both* a Map view and a custom set of map methods, which goes against the goal of keeping things simple. BR, Jukka Zitting
