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:13:13 +0000
To: public-script-coord@w3.org
Message-ID: <bug-29004-3890-e4OADGituu@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29004

--- Comment #10 from Domenic Denicola <d@domenic.me> ---
> So maybe instead of freezing the array, we could mark all the properties 0-length and "length" itself readonly noncofigurable, but allow adding other random properties...  It's a lot more complicated than just freezing, but is the minimal thing with the desired behavior.

Not sure what mark all the properties 0-length means. But in general schemes
like this do not work well because there's no way to prevent `array[1000] =
"test"` (which, in a real array, will then update `array.length` to be `1001`).
Additionally, Jonas's

> If we don't freeze the Array, that would mean that custom properties set on myInputElement.files will appear to "disappear" if a file is added.

is very important to keep in mind.

---

In general I agree that asking for more frozen objects is not great. However I
see no problem with objects that have non-writable data properties. (I'd leave
them configurable though.)

I don't quite understand how `readonly attribute
FrozenArray<NotificationAction> actions` works. Since NotificationAction is a
dictionary, and thus reified by value, I assume a new JS object is generated
for each array element, each time `.actions` is called. But `.actions` is a
frozen array, so its elements cannot change. Maybe there is an implicit "only
reify the dictionary once" going on? But it is not obvious to me how that falls
out.

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

This archive was generated by hypermail 2.3.1 : Friday, 31 July 2015 20:13:15 UTC