On Mon, Mar 22, 2010 at 2:19 PM, Freeland Abbott <[email protected]> wrote:
> The claim is that you make an ImmutableFoo by "freezing" a MutableFoo, > after which the invariant is that no client will change that collection. It > isn't a copy, it's a freeze of the thing, so the flag blocks you from > changing via the original MutableFoo handle. > > Contrast with vanilla Foo, which doesn't have an API for you to change it, > but is allowed to change by some other bit (e.g. I have a MutableFoo, and > return to you casting to Foo... I can change it, you can't). > > If you want a copy, copy it yourself (and pay the copy cost explicitly, > then freeze one, and you can go on changing the other). Bruce wants to run > pretty close to the wire, so if you mess it up assertions will tell you > about the error, but optimized it doesn't, and YMMV w.r.t. the effects. > Since devmode is always asssertions-on, the expectation is you'd find the > error soon. > There was a long discussion about this very point on the original wave of the design. The problem I have with it is a client may have been given a MutableFoo and then at some point later that same object gets frozen and it is no longer mutable, and MutableFoo operations will fail on that object without any notification of the client that got the MutableFoo that its contract had changed. You can work around it with conventions, but it seems -- John A. Tamplin Software Engineer (GWT), Google -- 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.
