[Bug 23682] Fix the current [ArrayClass], [] and sequence<T> mess

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682

--- Comment #31 from Mark S. Miller <erights@gmail.com> ---
(In reply to Jonas Sicking from comment #30)
> (In reply to Mark S. Miller from comment #21)
> > As one example, the array of literal parts of
> > a template string is deeply frozen, so that it can be safely shared among
> > the multiple evaluations of the same template string expression.
> 
> Mark: can you confirm that Object.freeze() for an Array indeed makes the
> Array immutable?
> 
> Object.freeze() in general doesn't make things immutable, however in the
> special case of Arrays, it appears that it does. Could you confirm that that
> is the case?
> 
> And that there's no risk that future changes to Array might introduce some
> way of mutating frozen Arrays? Is the template string feature freezing
> Arrays in order to make them immutable, or is it doing so in order to
> accomplish some other goal?

Yes, for arrays and also normal non-exotic objects. The same qualifier applies
to both claims:

var x = 8;
var a = [];
a.incX = function(){return x++};
Object.freeze(a);

a is of course not immutable in two senses:

a.incX() both causes and senses mutation.
a.incX itself is not frozen, and any objects within the array may also be
unfrozen.

Also, a inherits from Array.prototype, which the above code has also not
frozen.

My guess is that you are perfectly aware of these qualifiers already and
properly unconcerned about them. But it's always good to err on the side of
being explicit about hazards ;).

For exotics, we need to examine each on a case by case basis. That's why ES6
requires that Date.prototype is not a Date -- so that freezing it can make it
immutable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 6 October 2014 23:10:37 UTC