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.

Reply via email to