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.

Reply via email to