Can you outline a use case? I don't get it. My argument isn't with isFrozen, it's with the freezing feature per se. I can't see a reasonable use for it.
On Mon, Mar 22, 2010 at 11:03 AM, Rodrigo Chandia <[email protected]>wrote: > isFrozen allows assertions on the status of a mutable collection. During > normal use (assertions disabled), there should be no need to call isFrozen. > Moreover, using isFrozen outside of an assertion, or while assertions are > disabled, is not guaranteed to work at all. The intention is to avoid having > to pay a runtime penalty and discourage defensive programming. > > Related to the review, it was not my intention to introduce isFrozen just > yet (but it slipped through, sorry). isFrozen is a construct that only makes > sense when when Immutable classes are introduced, along with assertions and > tests relevant to immutability. At this point I wanted to concentrate on the > Mutable and the parent Read-only classes. > > Is isFrozen still a bad idea when used for assertions only? > > > 2010/3/22 <[email protected]> > > Can someone explain why isFrozen is a good idea? It sounds really, >> really bad to me. >> >> >> http://gwt-code-reviews.appspot.com/232801/show >> > > -- 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.
