I think you're missing my point. An object is immutable if there exists no api to mutate it. That should be enough.
Let me put it another way. It's lame that the JRE achieves immutability by turning mutate methods into runtime errors. It will be equally lame of us to do the same, especially since we can't enforce it at production time. It would be much better to provide an api such that there is not even possible to compile the mutate call (without cheating with casts, but then you know you're being bad). The Cocoa approach to this is to have interfaces like NSArray be immutable, and then have NSMutableArray extend NSArray. If we're going to roll our own collection classes, it seems to me we could do the same: e.g. LiteImmutableList and List extends LiteImmutableList. rjrjr On Mon, Mar 22, 2010 at 2:12 PM, Rodrigo Chandia <[email protected]>wrote: > I like the *concept* of immutability being introduced early in the > development. The initial implementation may be limiting for some use cases, > but I believe it is a useful concept to expand on. If specific needs require > simultaneous mutable and immutable access we can provide implementations to > address that problem (copy on write semantics, for example). > > 2010/3/22 Ray Ryan <[email protected]> > > I guess I'm overstating my opposition. It's not really dangerous, but it >> just doesn't seem useful. Just by existing I think it'll promote confusion >> and perhaps bad habits. Why bother? >> >> I think the 90% use case is for something like the following (writing in >> JRE terms here): >> >> private final List<String> magicValues; >> { >> List<String> buildValues = new ArrayList<String>(); >> buildValues.add("able"); >> buildValues.add("baker"); >> buildValues.add("charlie"); >> magicValues = Collections.unmodifiableList(buildValues); >> } >> >> Ta da: it's a read only structure and no copy was made. In our world, we >> could do better: >> >> private final ImmutableLiteList<String> magicValues; >> { >> LiteList<String> buildValues = new LiteList<String>(); >> buildValues.add("able"); >> buildValues.add("baker"); >> buildValues.add("charlie"); >> magicValues = buildValues.immutableView(); // more equivalent of cast() >> } >> >> The user never thinks in terms of freezing, just cutting off access. No >> extra dev mode mechanism to maintain, and basically the same idiom already >> in use in Java. >> > > -- 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.
