- From: <nobody@w3.org>
- Date: Fri, 31 Jul 2015 20:13:13 +0000
- To: public-script-coord@w3.org
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