On May 16, 2011 11:06 AM, "BobV" <[email protected]> wrote: > > On Sun, May 8, 2011 at 10:08 AM, Patrick Julien <[email protected]> wrote: > > Here is what I am planning to do to fix issue 6068 > > > > http://code.google.com/p/google-web-toolkit/issues/detail?id=6068 > > > > 1. Add to BeanMethod.java (package > > com.google.web.bindery.autobean.vm.impl;) an TO_ARRAY value > > > > 2. Add to JBeanMethod.java > > (com.google.web.bindery.autobean.gwt.rebind.model;) an TO_ARRAY value > > > > 3. in AutoBeanFactoryGenerator#writeShim (package > > com.google.web.bindery.autobean.gwt.rebind;) handle the TO_ARRAY case > > by checking the: > > > > a. if the type is assignable to Collection<?> > > b. Determine if toArray has one of two supported method signatures in > > Collection<?> > > c. Generate code that assigns each element of the newly created array > > by wrapping it first > > This sounds reasonable to me. > > > 4. Add a unit test to check for unfrozen beans. > > > > a. Get a collection of AutoBeans > > b. assert they are frozen > > c. Initialize an ArrayList using this other collection > > d. Assert the objects stored the second ArrayList are unfrozen > > The objects stored in the second ArrayList would still be frozen.
Then i'm confused. If the objects in the second array are still frozen, then the bug is still there no? The fact that the second ArrayList is still frozen is what makes ListEditorWrapper/HasDataEditor completely unusable for me. > It's the AbstractRequestContext and BaseProxyCategory that produces > the frozen/unfrozen behavior by cloning the AutoBeans as they're being > read though the external methods facades. > > I think the test that you want here is to ensure that Nth element of a > wrapped collection's toArray() is the same as the Nth element of the > collection. That is, list.get(0) and list.toArray()[0] are both > wrappers. > > > Open Questions: > > > > 1. Should I try to handle immutable collections, i.e., > > Collections.unmodifiable* or guava's Immutable*? > > The mutability of the collection shouldn't matter here, since > toArray() either returns a newly-allocated array or fills in the array > passed to toArray(T[]). > > > -- > Bob Vawter > Google Web Toolkit Team > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
