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

Any Array-like that doesn't let us type-check insertions is really missing the boat.  With any other attribute type, I can ensure that the object is of a known type, and the author messing that up will fail early, at the point you try to make a mutation.  This makes it much easier to write specification prose, as I'm working with a known type, and reduces the amount of type-checking that has to be done overall in the platform.  (In particular, when passing the object to *another* API, it can depend on the object's attributes all being of the correct type too, and doesn't have to repeat all the checks, recursively until you hit primitives.)

A non-type-enforceable Array subclass throws all this away. Spec authors have to be much more careful when writing their prose, which they *will* get wrong, and the platform has to recursively check that Array subclasses hold the right type *every single time it passes into browser-land code*. (Again, recursing all the way down to primitives, or at least to types that the engine knows ahead of time can't recursively-contain any array subclasses.)  Page authors have a more difficult time too, because inserting a bad value won't fail immediately; instead it'll throw at some later point when the collection is passed to a platform API and fails its recursive typecheck.

It's seriously not worth subclassing arrays if we can't get this right.  If this requires further ES changes (such as defining the `[]` hook that AWB proposed years ago), so be it, but let's not faff about with *more* half-solutions a la `[LegacyArrayClass]`, `FrozenArray<>`, etc.

-- 
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-296854017