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

*Whatever* typed arrays do (and it's not defined Proxy-like in the ES spec), it's clearly Good Enough for the web platform, tc39, and engines for it to be specced, shipped, and used.  The plan here is to lean on that exact mechanism.

Here are the alternatives:

1. I say "fuck it" and just use indexed getters/setters, which definitely invoke a proxy. (And define a mixin that adds all the array methods.)
2. I add `.get(i)` and `.set(i,v)` methods to the interface. (And define a mixin that adds all the array methods.)
3. I use plain iterators, and users have to manually cast them to an Array, fiddle, then construct a new object from the Array, every time they want to mutate something.
4. I use plain Arrays in an attribute of the class, and then have to insert at the top of every single function that takes a CSSNumericValue, CSSUnparsedValue, or CSSTransformValue "1. Check if the |foo| arg has any random crap in it, and throw a TypeError if it does.".  Note that for CSSNumericValue this involves recursively searching an arbitrarily-deep tree: <https://drafts.css-houdini.org/css-typed-om/#complex-numeric>.  (And as a result, the other two can also host trees, as they can contain numeric values.)

All of these suck to varying degrees.  Copying Typed Arrays is the only option that *doesn't* have crap ergonomics, as it puts array-likes on the same footing as map-likes and set-likes, and every other interface in the web.

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