Re: Immutable Datastructures with good Sharing
On Sun, 6 Nov 2011, Giovanni Azua wrote:
I haven't read/followed the whole OP Thread discussion but I thought it was
worth mentioning/recommending the Google "Guava Project":
http://code.google.com/p/guava-libraries/
I think they really "went to town" on that one. You have strongly typed
Immutable Collection definitions for all Java Collection types e.g.
ImmutableMap.Builder, ImmutableList.Builder.
If you had read the whole thread, or indeed just the OP's initial post,
you would understand that these classes are not helpful. They are
certainly immutable, they don't have the sharing properties that Jan is
after. They also don't expose any methods for doing the quasi-mutation he
needs to do.
To recap, Jan wants to be able to say:
ImmutableStack<String> a = new ImmutableStack<String>(); // empty
ImmutableStack<String> b = a.push("foo");
assert a.isEmpty();
assert b.size() == 1;
That is, the quasi-mutation creates a new instance exhibiting the change,
rather than changing an existing instance.
The Guava Immutable* classes do not have such methods.
The design is awesome e.g. the Builder pattern as prescribed in
Effective Java (last edition)
I find the builder pattern immensely annoying, myself.
and the performance gains are noticeable as well e.g. In a distributed
system I have been working on lately, switching the attribute instances
of the DTO Beans from ArrayList Java Collection to use instead the
implementation from Guava gave some noticeable 15-20% Serialization
performance gain e.g. Test case involving 1-Echo-Server and 1K-Clients.
That is a respectable gain!
I really enjoy the improvement in code readability as well, it suits the
appropriate template types e.g.
// from
List<RequestData> requests = new ArrayList<RequestData>();
// to
List<RequestData> requests = Lists.newArrayList();
I see absolutely no improvement in the code here, only unhelpful
obfuscation.
tom
--
Taking care of business