My argument is that one is necessary and sufficient. Two is kind of pointless if you have achieved one, and maybe even counterproductive.
On Mon, Mar 22, 2010 at 2:32 PM, Joel Webber <j...@google.com> wrote: > 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 <rj...@google.com> 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 <rchan...@google.com>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 <rj...@google.com> >>> >>> 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. > -- 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.