Am I right to think that the problem with builder.create() is that it implies a defensive copy, to allow you to do builder.add() afterwards, and we want to avoid that? (If not, then what is the problem?)
The solution to that could indeed be a more clever builder: at create() time, we return the existing array as an ImmutableArray, *and let go of it in the builder, moving it to a previousList filed or somesuch.* If the user does indeed later reuse the builder with some add() (or remove() or whatever), we do the defensive copy then, lazily. Presumably two back-to-back create() calls could just return the same list, since it's immutable anyway. I think I like that, personally. Thoughts? On Thu, Mar 25, 2010 at 2:05 PM, Daniel Rice (דניאל רייס) <[email protected]>wrote: > I have the feeling that if we pushed on the API a bit we could satisfy > all the constraints without having to do anything weird. The only downside > would be somewhat more interfaces to understand. For example, the builder > could have create() and createFrozen() methods -- a clever builder > implementation could still manage to share state between created instances > in some cases. > > Dan > > On Thu, Mar 25, 2010 at 1:58 PM, Bruce Johnson <[email protected]> wrote: > >> On 3/25/10, Daniel Rice (דניאל רייס) <[email protected]> wrote: >> > 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? >> >> (How exactly would the builder and mutable array classes differ? All >> of the points below rest on there not being a meaningful difference.) >> >> I agree it's a little weird not to have a builder, but then again, it >> would be weird to have a builder with freeze() instead of create() >> that can be called multiple times. To me, it's worse to purport to >> follow a pattern people assume they understand intuitively (i.e. >> Builder in this case) but then have different functionality (freeze >> vs. create) than to simply say, "It's unusual, but easy to learn and >> maximally efficient". >> >> And there's also an argument to be made that fewer classes are easier, >> all else being equal. Which would favor not having a builder that is >> quite redundant to mutable array. >> >> -- Bruce >> >> -- >> >> 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.
