If at the end of the day freezing is going to have a side effect on the original collection, moving the freeze call to a static method seems pretty mysterious to me. I think you just suggested something like this pseudocode:
MutableArray myArray = new Array("able", "baker", "charlie"); ImmutableArray solid = Collections.freeze(myArray); myArray.add("delta"); // assertion fails That indirection of that side effect seems worse than it would be from an instance method, where it's much more intuitive that I'm messing with the object itself. Did I misread? FWIW, I'm pretty solidly with Bruce now. rjrjr On Fri, Mar 26, 2010 at 9:01 AM, Rodrigo Chandia <rchan...@google.com>wrote: > I like having an absolutely most efficient way to take my data from a > mutable array into an immutable one called freeze. I also believe that > freezing should not be the only way to obtain immutable objects. > > I propose moving the freeze operation to a static method in Collections. > This is my way to say freezing should not be an inherent property of mutable > arrays (but support for the frozen assertions is). Building an immutable > collection by copy, using a builder object, or any other means should be on > equal footing to freezing, as an external operation. > > The implementation plan then will be (in order): > > * ImmutableArray + freezing > * Maps, Mutable Maps > * Immutable Maps + freezing > * Revisit builders, immutability and how it relates to operations (aka > Actions) such as map, filter, reduce, etc. > * Actions and Predicates > > Rodrigo > > 2010/3/25 Bruce Johnson <br...@google.com> > >> What John said. JSO cross-casts allow this. >> >> >> On Thursday, March 25, 2010, John Tamplin <j...@google.com> wrote: >> > On Thu, Mar 25, 2010 at 6:07 PM, Rodrigo Chandia <rchan...@google.com> >> wrote: >> > >> > >> > (Sorry for the spam, Bruce. I forgot to press reply to all.) >> > >> > I seem to be missing some piece from the puzzle: in which way does >> > freezing a MutableArray prevent the allocation of an ImmutableArray >> > object? >> > >> > // This creates a new MutableArray instance >> > MutableArray ma = CollectionsFactory.createMutableArray(); >> > ma.add("x"); >> > ma.add("y"); >> > ... >> > // But freezing will also instantiate another object, right? >> > ImmutableArray ia = ma.freeze(); >> > >> > Internally, freeze will perform something like: >> > >> > return new ImmutableArrayImpl<E>(elem); >> > >> > Or is it that in prod mode we can do special tricks to avoid the >> creation? >> > In Javascript, you simply cast MutableArray to ImmutableArrayImpl and >> return the same object. >> > >> > >> > -- >> > John A. Tamplin >> > Software Engineer (GWT), Google >> > >> > >> > -- >> > http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > >> > To unsubscribe from this group, send email to >> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to >> this email with the words "REMOVE ME" as the subject. >> > >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> >> To unsubscribe from this group, send email to >> google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to >> this email with the words "REMOVE ME" as the subject. >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > > To unsubscribe from this group, send email to > google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to > this email with the words "REMOVE ME" as the subject. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.