Oliver Hunt wrote: > On Nov 5, 2009, at 10:14 PM, David-Sarah Hopwood wrote: >> Oliver Hunt wrote: >>> I disagree here -- i believe mutable vs. immutable data is different >>> from unfrozen and frozen objects [...] >> >> Why? What would the hypothetical Data.prototype.freeze do that would be >> different to applying Object.freeze to a Data object? >> >>> (though i agree that the function names >>> freeze and frozen are just asking for problems in conjunction with ES5 >>> :D ). There are plenty of times where I would want to provide immutable >>> data (the UA sharing content, etc), but i may still want to modify the >>> object itself. >> >> Oh, you mean that you want *read-only* Data objects backed by a mutable >> array. That is not the same thing as an immutable (or "frozen") Data >> object. > > No, the issue here is that Charles has conflated object freezing with > immutable data,
That isn't conflation; they're the same.
> frozen objects and immutable data are not the same thing
You are mistaken. This is a case where terminology across languages is
quite consistent, and is as I've described it. "Frozen" means exactly the
same thing as "immutable", and implies that the state of the object will
never be observed to change [*]. An object is "read-only" if there is no
means to directly change its state via a reference to it, which does not
necessarily imply that its state cannot be observed to change.
> -- for instance in the DOM I cannot set indices of a NodeList, but the
> NodeList does not need to be frozen.
NodeList objects are read-only.
[*] It is ambiguous whether indirectly referenced state can change; if
it is important that it cannot, say "deep-frozen" or "deeply immutable".
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
