[guava] Can guava help me on the most irritating collections issue?

[paulo]

That is the iterator + multiple collections to remove from yhe
iterator values. You have to know what collection the values came from
to avoid the bogus concurrent modification exception, so you can't
abstract that part into a function apart. Best case you have many
functions with extremely similar code or nasty hacks involving
creating new iterators as you remove one by one, or a defensive copy.

[Tim Peierls]

I don't understand the question.

--tim

--
guava-...@googlegroups.com.
http://groups.google.com/group/guava-discuss?hl=en
unsubscribe: guava-discus...@googlegroups.com

This list is for discussion; for help, post to Stack Overflow instead:
http://stackoverflow.com/questions/ask
Use the tag "guava".

To unsubscribe from this group, send email to guava-discuss+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Dimitris Andreou]

I think he tries to say that code like this:

collection.remove(o);

may fail if the collection is being iterated higher in the call-stack, so those two pieces of code can't be composed, while individually each may be working fine.

So if the question is whether guava can alleviate this problem, the answer is no - code that removes elements from collections that might throw CME must either assume that no iteration takes place, or must somehow get access to the iterator, such is life.

Dimitris

2010/3/29 Tim Peierls <t...@peierls.net>

[Tim Peierls]

ConcurrentHashMap iterators don't throw CME.

--tim

[paulo]

Err, just realized that if i call iterator.remove() before sending the
value to be removed from the collection mess it will not throw cme
because there is nothing to remove so the modcount will not be
altered.

I am enlighted. Just took some thought.

[Johan Van den Neste]

Immutability is bliss if it is doable within your use case.
Copy on modify is sometimes much more efficient than defensive copying
all over the place.

But unfortunately guava still lacks some basic functionality to make
working with immutable collections user friendly. (Last time i
checked, that is. But that may have been a while ago)

Johan Van den Neste

[Kevin Bourrillion]

On Tue, Mar 30, 2010 at 7:58 AM, Johan Van den Neste <jvdn...@gmail.com> wrote:

But unfortunately guava still lacks some basic functionality to make
working with immutable collections user friendly. (Last time i
checked, that is. But that may have been a while ago)

Such as?

--
Kevin Bourrillion @ Google
internal:  http://goto/javalibraries
external: http://guava-libraries.googlecode.com

[Johan Van den Neste]

>> But unfortunately guava still lacks some basic functionality to make
>> working with immutable collections user friendly. (Last time i
>> checked, that is. But that may have been a while ago)
>
> Such as?

Making new immutable maps from existing maps with some mappings
removed or added. (unless it was added, and I missed it, for which I
apologize).

http://code.google.com/p/guava-libraries/issues/detail?id=306&can=1&q=jvdneste

Also, the performance of these operations is bad. There are better
ways of implementing immutable map and lists. "Better" is the wrong
word: they have different performance characteristics making adding
and removing mappings cheaper but lookups slightly more expensive. (as
in clojure, and, I suspect, scala 2.8, but i haven't found any details
on that yet)

But I repeat myself. It's just that I find working with immutable
structures very productive. There's a lot less to worry about. (except
performance).

I must admit I haven't picked up on guava yet, but I will do so once a
binary has been released and the discussed api stability annotations
are in place.

--
Johan Van den Neste

[Benjamin Manes]

What you're asking for are called persistent data structures and, imho, would serve a different purpose than what the immutable collections are intended for. These types of data structures are very valuable, but should be defined as separate types. The immutable collections assert that mutations are not allowed while a persistent data structure produces a new persistent version on an update, but does not change the original. As their contract differs from the immutable collections this would require an additional set of data types. Guava's immutable collections are friendly for their intended purpose and a persistent form may be a valuable addition.

--
guava-...@googlegroups.com.
http://groups.google.com/group/guava-discuss?hl=en
unsubscribe: guava-discus...@googlegroups.com

This list is for discussion; for help, post to Stack Overflow instead:
http://stackoverflow.com/questions/ask
Use the tag "guava".

To unsubscribe, reply using "remove me" as the subject.

[Johan Van den Neste]

As (clojure's) persistent datastructures have different performance
characteristics, I most definately agree that they should not replace
the current immutable structures as a matter of leaving people the
choice of the right tool for the job. I don't agree with them having
different contracts though. Immutable is the same as persitent. What
can you do with a persistent structure that you cannot do with an
immutable structure and vice versa?
Does the term 'persistent' for you refer to a specific immutability
contract or a specific implementation of immutable structures?

--
Johan Van den Neste

[Joseph Wofford]

Persistent data structures are immutable, but not all immutable data structures are persistent.

Consider the difference between the add method in ImmutableCollection and the concat method in String:
    boolean add(E e)
    String concat(String str)

The add method in ImmutableCollection throws UnsupportedOperationException.

The concat method in String returns a new String leaving the original unchanged.

String is the closest thing Java has to a persistent data structure. It's immutable, but it has methods like concat and replace that change without mutating.

The methods that change Java collections on the other hand are simply incompatible with immutability and cannot be supported.

The methods that "change" persistent data structures really transform them leaving the original data structure intact.

The trick is to do this efficiently, but there's an extensive literature on persistent data structures and algorithms and efficiency is quite possible in many cases.

[Pat Farrell]

Making new immutable maps from existing maps with some mappings
removed or added. (unless it was added, and I missed it, for which I
apologize).

Isn't that an ideal place to use a filter? Define a filter that does the exclude logic, and then call a function to apply the filter to the old map, returning a new Iterable, which you can feed to make an immutable copy. 

[Kevin Bourrillion]

I have more commonly seen these called "purely functional data structures", as in

http://www.amazon.com/Purely-Functional-Structures-Chris-Okasaki/dp/0521663504

A Googler once contributed to us a stack implementation like this, over a year ago, but so far not a single soul has used it.  I would be surprised if this was an area that you'll see covered in Guava in the foreseeable future.  

[Kevin Bourrillion]

s/Iterable/map/, but yes, this is how you have to do it.  It's not hard to imagine a more convenient API for doing this, though.

[Pat Farrell]

On Wed, Mar 31, 2010 at 11:28 AM, Kevin Bourrillion <kev...@google.com> wrote:

s/Iterable/map/, but yes, this is how you have to do it.  It's not hard to imagine a more convenient API for doing this, though.

That's what I meant. of course.

Given the big thread on "The Guava conundrum" I'm not a big fan of convenience APIs right now. Once all the experimental and testing code is solid, then it becomes a bit more attractive.

 

[Johan Van den Neste]

> Isn't that an ideal place to use a filter? Define a filter that does the
> exclude logic, and then call a function to apply the filter to the old map,
> returning a new Iterable, which you can feed to make an immutable copy.

public static <K,V> ImmutableMap<K,V>
with(final ImmutableMap<K,V> map, final K key, final V value) {
return ImmutableMap.<K,V>builder().putAll(Maps.filterKeys(map,
Predicates.not(Predicates.equalTo(key)))).put(key, value).build();
}

is what I have.

But it's hardly efficient.

[Johan Van den Neste]

>>> Making new immutable maps from existing maps with some mappings
>>> removed or added. (unless it was added, and I missed it, for which I
>>> apologize).
>>
>> Isn't that an ideal place to use a filter? Define a filter that does the
>> exclude logic, and then call a function to apply the filter to the old map,
>> returning a new Iterable, which you can feed to make an immutable copy.
>
> s/Iterable/map/, but yes, this is how you have to do it.  It's not hard to
> imagine a more convenient API for doing this, though.

True. I'm not criticizing the existing api. I'm just saying that the
with/without methods can be implemented much more efficiently within
guava, and that it shouldn't get the 'convenience' label as a result.
(I think I called them convenience earlier. That was a mistake)