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.
