jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jr3] Tree model
Date Tue, 28 Feb 2012 21:43:07 GMT

On Tue, Feb 28, 2012 at 7:10 PM, Michael Dürig <mduerig@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.


Jukka Zitting

View raw message