First comment, I'm glad we've provoked this re-discussion, because "the original wave" was by definition not public.
Back to your regular programming, I think the *intended *pattern is that a given mutable thing would only be "owned" by one entity, which would therefore have control of whether it was frozen or not. So, the argument probably comes down to whether there's a good use case that violates that expectation. The example I can think of is something like a shared bus, where several clients might add items to the queue... but the Java idiom for that would we to embed the mutable list into an EventBus or WorkQueue instance anyway, and so it would be the owner, and clients would call an addItem(foo) method on that wrapper. The other argument, of course, is just that given rope, *somebody* will tie a noose and stick their head into it... it's not clear we have to stop them, though it'd be nice to. But if we don't stop it, we'd like it to be easy for them to figure out what they did wrong and what to do about it! On Mon, Mar 22, 2010 at 3:18 PM, Bruce Johnson <br...@google.com> wrote: > @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. > -- 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.
