Re: [heycam/webidl] Introduce the observable array type (#836)

After a bit more work hacking on the proxy variant (to fix the issues noted in https://github.com/heycam/webidl/issues/796#issuecomment-578273849), I'm coming around to @othermaciej's point of view, that we make the hooks behave like indexed setters (and the no-longer-in-the-spec indexed deleters).

The reasoning is a bit subtle. It turns out maintaining an accurate "observable array backing contents" list is not really possible due to the potential for holes in the array. For example, consider JS code such as

```js
// Creates 3 holes at indices 0, 1, 2
building.employees.length = 3;

building.employees = [new Employee("A"), new Employee("B")];

// Creates a hole at index 0
delete building.employees[0];
```

One might ask, can we disallow such code? It turns out no, at least not if we want array methods to work, because array methods often create such holes "temporarily". E.g. `building.employees.pop()` is defined (by ECMAScript) to be equivalent to

```js
// Create a temporary hole
delete building.employees[building.employees.length - 1];

// Truncate the array, removing the temporary hole
building.employees.length = building.employees.length - 1;
```

and there's no way to distinguish these kinds of "temporary" holes (which we want to allow) from the more long-term ones created by the above snippets.

Given this, the "backing observable array contents" I was trying to preserve will either:

- Contain holes, forcing specification authors to deal with them; or
- Be a more complicated structure, e.g. a list of (item, indexInTheArray) tuples or a map of indexInTheArray -> item entries, so that the Web IDL spec machinery can properly keep it synchronized. And this more complicated structure would be a nightmare for specification authors to deal with, as e.g. you couldn't append to it without figuring out the proper index, or remove the first item without shifting down all the others.

So I'm thinking that a simple indexed setter/deleter-type infrastructure will be good enough instead, since the perceived benefits of the proposal in this PR don't really materialize.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/836#issuecomment-580913174