On Thu, Mar 25, 2010 at 2:16 PM, Freeland Abbott <fabb...@google.com> 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?) > > 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. > That works fine It won't always optimize as well, though. For a builder created in one method, built up, and then turned into an immutable collection, anything goes. Unwrap the fields of the builder object, inline the add/remove/etc methods, and use data flow for the rest. However, for a builder passed around to multiple methods, this looks much harder, and surely the optimizer won't always figure it out. For freeze, I presume it works out that in the prod-mode version the frozen collection really is the same object? In that case, we should get the tightest possible code just by inlining add/remove/etc. There isn't any fancy inference needed to prove that add() is never called after create(). -Lex -- 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.
