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

--- Comment #13 from Travis Leithead [MSFT] <travil@microsoft.com> ---
(In reply to Jonas Sicking from comment #9)
> For example, it means that the HTMLInputElement.files can return the same
> object every time that you get it. If the user attaches another file, we
> simply create a new Array and return that.
> 
> 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.
> 
> Ideally we would use something like "value objects" rather than frozen
> Arrays, however JS doesn't currently have those so that's not an option.
> 
> So I think frozen semantics is what we're actually looking for. Not just
> "can't add or remove entries to the Array".

This sounds like you want a pattern for describing (in general) how "live
lists" work, except that you're willing to violate the invariant of
object-identity from time-to-time.

```var fileListRef = input.files;```

Most of the time (until something causes the list to change):

```fileListRef === input.files;````

I'm concerned that this third-state is a dangerous metaphor because of its
unpredictability for the author. With static lists (e.g., result of qSA) the
author can understand that the list is always a snapshot, and with live lists
(e.g., node.childNodes) the author can understand that the list is always
current and up-to-date. Applying FrozenArray to live-list-like scenarios
creates a third state whereby you can't make either of these assumptions--and
it requires you to have some additional mechanism of being informed of when
your list-of-origin changes.

I would much rather have a solution that solves and preserve the invariants of
the live list, because I think that is what you actually want for these cases.
It's a relatively-slow-updating live list--you just want it to act more
array-like than our current flavor of interfaces (HTMLCollection, NodeList,
etc.). I think we also want a single 'type' of list rather than having to
re-invent another XThingList that has the same semantics.

Using FrozenArray in place of a live list solution will take away:
1. Object identity consistency
2. Object extensibility
which I think are two important characteristics to preserve.

What Boris proposed is close to a live-list replacement: it preserves identity,
it preserves extensibility, it forbids mutation of the list values. I think we
are close to having something feasible for a live-list replacement. It would
meet the requirements of being able to return the same object each time--and
rather than replace it with a new one when the list changes, you would simply
clear the old list's contents and add the new values (or do something more
intelligent to modify the original object's contents). This is possible so long
as you don't take the extra step of marking all the [0 to length] properties
non-configurable.

Of course, leaving the indexed properties configurable, means that author code
could lock them down by setting configurable=false. We'd have to define how
platform code would respond to such an event, or suggest that ECMAScript
provide a mechanism to prevent properties from become configurable=false in the
first place as well as preventing preventExtensions() on the object. (e.g.,
something like enforceExtensions()).

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

This archive was generated by hypermail 2.3.1 : Monday, 3 August 2015 17:28:34 UTC