Immutability is a stronger assertion than read-only access. If I receive a
read-only object I better make sure to handle the case of the data being
changed by others; be it by tacit agreement, using other channels, locking
or simply ignoring the issue. Immutability guarantees the data is stable and
unchanging. The agreement is explicit. I will be able to read it to my
heart's content without worry.
Granted, being this a simple implementation it has some inconveniences:
1. The Immutability is achieved by "freezing" the original Mutable container
while it may be useful to keep working with the original container instead.
2. The receiver of a MutableArray may find later that someone called freeze
on the object causing an error.
This is largely a matter of it being a lightweight implementation. There is
no contract forcing the mutable view to be tied to the original mutable
container. A more sophisticated implementation could copy the container,
implement copy-on-write semantics, or any number of alternative
implementations. Still the meaning of an immutable collection implies the
contents will not change, while a read-only view makes no such promise.
2010/3/22 Ray Ryan <rj...@google.com>
> 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.
