@John: I totally agree that's a risk, but then again, the situation you describe would arguably be a bug anyway -- or at least I'd call it under-specified. Indeed, I hope that in people's paranoia to avoid those situations, that they are more thoughtful about the types they hand around in their API, using the exactly the right semantics for the situation at hand.
And, of course, there are always tradeoffs in design. The design of these classes to enable people who are coding things correctly and clearly to not suffer one iota of overhead for which they don't get commensurate value. That's same reasoning is why it will use assertions instead of exceptions. On Mon, Mar 22, 2010 at 3:05 PM, John Tamplin <j...@google.com> wrote: > On Mon, Mar 22, 2010 at 2:19 PM, Freeland Abbott <fabb...@google.com>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.
