I think we're talking about two different things here. Rodrigo's (valid) point is that implementing immutability sanely early on is a good idea. And this implementation is pretty much analogous to the one you describe from Cocoa.
The question at hand is whether it makes sense to get an immutable collection from a mutable one, with no copies. There are two ways to do this: 1. Create an immutable "view" of a mutable list, but with no guarantees that the list won't be mutated by the original owner later. 2. "Freeze" a mutable list into an immutable view of said list, making the former "runtime immutable". (1) solves the problem of a class giving access to one of its internal collections without having to guard against external mutation. (2) can be used to replicate the "builder" pattern. I don't have a strong opinion about (2) myself, but (1) is pretty damned important, because it's the source of innumerable stupid defensive copies in JRE code. The provider of such an interface would just have to be very clear about whether the "immutable" list might be modified later (because it's a view on a mutable one). On Mon, Mar 22, 2010 at 5:23 PM, Ray Ryan <[email protected]> wrote: > 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. > -- 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.
