TimurMahammadov / google-collections

Automatically exported from code.google.com/p/google-collections
Apache License 2.0
0 stars 0 forks source link

Copy arbitrary collections #31

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Currently we can't really do this:
   Map<Customer> original = ...
   Map<Customer> copy = Maps.copyOf(original);

Because we don't know the runtime type of original. I propose the following:
  1. Introduce a Copyable<T> interface that allows Collections (and possibly other types) to 
provide shallow copies of themselves.
  2. Implement said interface for all collections in the API
  3. Create APIs that can copy an arbitrary Collections. For things that implement Copyable, this 
would use that. For the known set of collections in the JDK, this would copy 
these using the 
most appropriate mechanism. For everything else, this should fail with a 
RuntimeException.

Difficult stuff:
- deep vs. shallow copies. For collections, I believe shallow copies are best. 
I 'm not ready to 
expand the copyable interface to anything else.
- wrapped collections. How to copy a TreeMap that's been wrapped with 
unmodifiableMap?
- other views. What do we do when we copy the keySet of a TreeMap?

Original issue reported on code.google.com by limpbizkit on 1 Nov 2007 at 2:06

GoogleCodeExporter commented 9 years ago
What's the use case for that kind of copying? When writing application code, I'd
rather explicitly specify the class of the copy. To maintain the iteration 
ordering
of the original, you can use a class like a LinkedHashMap.

Original comment by jared.l....@gmail.com on 1 Nov 2007 at 5:14

GoogleCodeExporter commented 9 years ago
I'm thinking in particular of utility methods that return a copy of their input 
- this includes methods like 
intersection(), transform(), and filter() for various collections types.

Original comment by limpbizkit on 1 Nov 2007 at 4:51

GoogleCodeExporter commented 9 years ago
Quite simply, "a wish for a clone() that worked."

I agree that this would be good to support, for the same reasons that the 
(failed)
idea of clone() was created in the first place.

This would enable things like Sets.union() to do what people expect (I think).

btw, the other thing I'm aware of that you can't do generically to a collection 
is
get an unmodifiable view of it!

  public static <C extends Collection<?>> C unmodifiableView(C collection) { ... }

This seems closely related, in that to make it work, we'd have to have tedious
itemized support for all the JDK collections plus have some interface or 
something
that other collections would be required to implement if they want to 
participate.

Big Yuck for us, but possibly useful to users?

Original comment by kevin...@gmail.com on 2 Nov 2007 at 2:15

GoogleCodeExporter commented 9 years ago
clone() on collections, like on the jdk collections, would be useful.

I just got the following exception from eclipselink-2.0 M7, this is the 
reference
implementation of JPA-2.0.

Target Invocation Exception: java.lang.CloneNotSupportedException:
com.google.common.collect.Lists$TwoPlusArrayList
        at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commitInt
ernal(EntityTransactionImpl.java:102)
        at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commit(En
tityTransactionImpl.java:63)
        at org.metawb.astro.db.PersonTest.linkPersonTag(PersonTest.java:191)

FYI, This came from Lists.asList
        em.getTransaction().begin();
        for(int i = 0; i < 3; i++) {
            ps.get(i).setTagtypeCollection(Lists.asList(
                    tts.get(0), tts.get(i+1), new Tagtype[0]));
        }
        em.getTransaction().commit();

but this works ok

            ps.get(i).setTagtypeCollection(Lists.newArrayList(
                    tts.get(0), tts.get(i+1)));

Original comment by e...@raelity.com on 15 Sep 2009 at 6:17

GoogleCodeExporter commented 9 years ago

Original comment by kevin...@gmail.com on 17 Sep 2009 at 6:02

GoogleCodeExporter commented 9 years ago
This issue has been moved to the Guava project (keeping the same id number). 
Simply replace 'google-collections' with 'guava-libraries' in your address 
bar and it should take you there.

Original comment by kevinb@google.com on 5 Jan 2010 at 11:09