I disagree with point (1). The APIs are not the same, just almost the same. IMHO the builder should have a freeze method while the MutableArray should not. This makes it clear that freezing is a build-time process. It seems to me that this could be done with a little interface inheritance and probably wouldn't impact generated code size at all. Thoughts?
Dan On Mon, Mar 22, 2010 at 3:13 PM, Bruce Johnson <br...@google.com> wrote: > 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. > -- 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.
