On Thursday, March 25, 2010, Freeland Abbott <[email protected]> wrote: > 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?)
Yes, or to avoid having people call build() multiple times. Using a builder means at least two objects (builder + product(s)) for any array creation. > 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. These sorts of tricks usually bite us in both size and speed. Also, it doesn't avoid the "multiple allocations to get just one array" problem. > > 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. > -- 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.
