Re: [heycam/webidl] A new approach to array-ish classes (#796)

> It's not quite clear to me how the executor bits fit into the proposal. Is there an explanation somewhere?

No explanation, so here's a quick one. The intention is basically to allow these to be usable by web developers in the same way as they would be for spec authors. The executor in particular is an instance of the [revealing constructor pattern](https://blog.domenic.me/the-revealing-constructor-pattern/). The usage would be something like

```js
let controller;
const arr = new ReadonlyArray(c => {
  c.splice(0, 0, "a", "b");
  controller = c;
});

// later
controller.splice(0, 1);
```

and

```js
const arr = new ReactToAbleArray((item, index) => {
  if (isWrongType(value)) {
    throw new TypeError("Can only accept CSSStyleSheet instances or whatever");
  }
  
  reactToTheNewCSSStyleSheet(value);
});
```

> In theory we could do this for everything with an indexed getter already, modulo possible web compat issues for existing types, right? So the main benefits (and they're useful benefits!) of ReadonlyArray are that we know there is no web compat issue and we can avoid having a silly item method on it. Is that a correct summary of the ReadonlyArray situation?

I think the main other benefit is providing a clear path forward for future cases in the platform. Without something in the Web IDL spec, people would continue to need to invent them per-spec. Also we could wrap up some of the boilerplate for folks and provide sanctioned patterns for manipulating the contents of the collection.

Indeed, my OP was mostly thinking about what class to use for future properties. Retrofitting existing classes is probably also a reasonable thing to do, and the strategy there could look like one of:

- Switch specs to use these new classes, with potential web-compat pains (e.g. `.constructor.name` would change, `item()` methods would disappear, `isConcatSpreadable` behavior would change)
- Define some way of "mixing in" the appropriate behavior, e.g. `legacyarraylike<T>`, which would minimize the number of potential web-compat problems
- Just go through the spec systematically and upgrade them on a case-by-case bases

However, I'm unsure how much appetite there is for upgrading existing APIs, especially if there are compat risks. (I haven't run any of this by Chrome bindings team yet; instead it's motivated by the folks working on `adopedStyleSheets`.) So that's why I was focused on future cases for now.

Also, there is the potential benefit of providing these capabilities to web developers (via the `constructor()`s). That is not as urgent but it seems like the right thing to do.

> At least on the Gecko side, I suspect implementation complexity is much lower if we just do [LegacyArrayClass] instead of reimplementing all of that stuff. But maybe I'm missing something; I'd like to know what implementation benefits would come from the reimplementation approach.

I was mostly speculating, so it's probably not worth getting in to. I can't even remember very well what my speculation was :(.


-- 
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/issues/796#issuecomment-531102738