Re: [heycam/webidl] Figure-out what supporting Array-subclassing implies (#345)

> Does this imply new syntax?

It might be a good idea. We could hijack `: Array` or similar, but that'd be special-casing things.

On the other hand, it's hard for me personally to start brainstorming new syntax without boiling the ocean, so maybe sticking with existing syntax is better?

> New bindings?

Definitely.

> Are there specific requirements in terms of defining certain methods etc. that are required?

We may want to figure out the story for isConcatSpreadable; that was added specifically so that legacy classes could subclass Array: http://stackoverflow.com/a/27024188/3191. E.g. if NodeList became an Array subclass, it would set isConcatSpreadable to false so that it wouldn't break code. However, NodeList can't really subclass Array anyway since e.g. its read-only. It could do a fake-subclass via [LegacyArrayClass] + fixing isConcatSpreadable, maybe.

So new subclasses might want to just leave isConcatSpreadable alone.

----

I think our biggest issue is we need a consumer to help us shake out the bugs and edge cases. That used to be DOM's `Elements`, but that was removed since there was no implementer support (which was in turn at least partially because of the lack of Web IDL support).

The biggest question surrounds the fact that Array subclasses cannot control what type of items they contain. E.g. `Elements` could contain numbers or Nodes, not just Elements, via `els.push(5)` etc. So consumer APIs need to use `sequence<Element>` to get proper type-checking, and any methods defined on `Elements` need to properly skip or throw on non-`Element` members.

Resurrecting that spec might be enough, but having another spec as a second consumer would make me happier.

-- 
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/345#issuecomment-294844088