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: Mon, 03 Aug 2015 17:35:26 +0000
To: public-script-coord@w3.org
Message-ID: <bug-29004-3890-RODMV2ATtk@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29004

--- Comment #15 from Adam Klein <adamk@chromium.org> ---
(In reply to Jonas Sicking from comment #9)
> 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.

I'd like to better understand how this is supposed to work. Which of the
following two things are you suggesting should happen when a file is added?

1) The implementation mutates the otherwise-frozen array, extending the
"length" and adding a new indexed property.
2) The implementation returns a new frozen array, containing all the elements
of the old array plus an additional element.

(1) violates invariants of the language, as non-writable, non-configurable
properties should never change.

(2), while avoiding the problem of disappearing "expando" properties (by
disallowing them to begin with), still runs into identity issues. If
myInputElement.files has been stored somewhere, the old copy won't be updated.
It will also fail === comparisons with the new version. Similar identity-based
problems arise with using it as a key in a Map/Set/WeakMap/WeakSet.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 3 August 2015 17:35:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 3 August 2015 17:35:29 UTC