W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2015

[Bug 29004] FrozenArray only provides shallow immutability

From: <nobody@w3.org>
Date: Fri, 31 Jul 2015 20:27:05 +0000
To: public-script-coord@w3.org
Message-ID: <bug-29004-3890-jmBqLsh7w4@http.www.w3.org/Bugs/Public/>

--- Comment #11 from Boris Zbarsky <bzbarsky@mit.edu> ---
> Not sure what mark all the properties 0-length means.

  for (let i = 0; i < foo.length; ++i) {
    Object.defineProperty(foo, i, { ...., configurable: false });

> schemes like this do not work well because there's no way to prevent `array[1000]`

Sure there is.  If "array" is an actual Array or subclass thereof, marking the
"length" property as readonly nonconfigurable exactly prevents that, because
step 3.f will cause the property definition to fail.  Simple testcase:

  var arr = []; 
  Object.defineProperty(arr, "length", 
                        { value: 0, writable: false, configurable: false });
  arr[5] = 7;
  console.log(arr[5]) // undefined
  (function() { "use strict"; arr[5] = 7 })(); // throws

Jonas's point is a lot more important, though.  I hadn't though of that
problem. :(

> I don't quite understand how `readonly attribute
FrozenArray<NotificationAction> actions` works

A FrozenArray is a JS object (just like "object"), even in terms of its "IDL
value".  So in this case, whatever has that "actions" attribute internally
stores a JS Array object which is frozen.  The getter returns this internally
stored JS Array object.

> Since NotificationAction is a dictionary, and thus reified by value

It's reified by value at the point when the FrozenArray is created.  But after
that the FrozenArray just contains the JS object produced from the dictionary.

> Maybe there is an implicit "only reify the dictionary once" going on?

It's not implicit at all.  It's explicit in the creation of the FrozenArray
object, which is defined in

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 31 July 2015 20:27:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC