(Sorry for the spam, Bruce. I forgot to press reply to all.)
I seem to be missing some piece from the puzzle: in which way does freezing
a MutableArray prevent the allocation of an ImmutableArray object?
// This creates a new MutableArray instance
MutableArray ma = CollectionsFactory.
createMutableArray();
ma.add("x");
ma.add("y");
...
// But freezing will also instantiate another object, right?
ImmutableArray ia = ma.freeze();
Internally, freeze will perform something like:
return new ImmutableArrayImpl<E>(elem);
Or is it that in prod mode we can do special tricks to avoid the creation?
2010/3/25, Bruce Johnson <[email protected]>:
>
> 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.
