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/>

--- 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

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.4.0 : Friday, 17 January 2020 17:14:24 UTC