Here's how freeze() got introduced. You need to be able to have ImmutableArray without any mutators, and you need to be able to create them, thus you need a builder. A very frequent pattern will be to build up an array with a builder (the hypothetical ImmutableArrayBuilder) and then want to get an ImmutableArray from it. So, you'd often write this:
== BEGIN SNIPPET == ImmutableArrayBuilder b = new ImmutableArrayBuilder(); b.add(...); ... ImmutableArray ia = b.build(); // throw away b == END SNIPPET == A few observations about the above inevitable code snippet: 1) ImmutableArrayBuilder would have an API that's almost the same as MutableArray, so why make it a separate class? 2) The builder pattern typically allows multiple objects to be built from the same builder, but it's easy to imagine that typical uses won't actually want to reuse builder instances, thus we're paying for twice the number of object allocations (1 builder + 1 product) for the common case. Why solve it with freeze()? This design makes MutableArray into a builder of ImmutableArrays that is extremely efficient (since it will be implemented as "return this" and will use JSO cross-casting), thus avoiding the wasteful builder allocation problem. Secondly, the "freeze()" semantics don't open up the notion that a single MutableArray could be used as a reusable factory -- unlike build(), freeze() makes it obvious that you can't mess with the builder anymore. Hope that makes sense. As Freeland said, this design is based on the idea of maximum performance, minimum size, and a set of types that allows applications to avoid expensive allocations and copying. We need a rich enough set of types that, whatever the circumstances, you're never more than cheap (hopefully O(1)-time) operation away from having an object that satisfies the need. For example, we want to encourage handing out aliases to private fields (making it safe to do so by providing a read-only handle in the form of the root type). On Mon, Mar 22, 2010 at 2:06 PM, Ray Ryan <rj...@google.com> wrote: > Can you outline a use case? I don't get it. My argument isn't with > isFrozen, it's with the freezing feature per se. I can't see a reasonable > use for it. > > > On Mon, Mar 22, 2010 at 11:03 AM, Rodrigo Chandia <rchan...@google.com>wrote: > >> isFrozen allows assertions on the status of a mutable collection. During >> normal use (assertions disabled), there should be no need to call isFrozen. >> Moreover, using isFrozen outside of an assertion, or while assertions are >> disabled, is not guaranteed to work at all. The intention is to avoid having >> to pay a runtime penalty and discourage defensive programming. >> >> Related to the review, it was not my intention to introduce isFrozen just >> yet (but it slipped through, sorry). isFrozen is a construct that only makes >> sense when when Immutable classes are introduced, along with assertions and >> tests relevant to immutability. At this point I wanted to concentrate on the >> Mutable and the parent Read-only classes. >> >> Is isFrozen still a bad idea when used for assertions only? >> >> >> 2010/3/22 <rj...@google.com> >> >> Can someone explain why isFrozen is a good idea? It sounds really, >>> really bad to me. >>> >>> >>> http://gwt-code-reviews.appspot.com/232801/show >>> >> >> > -- 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.
