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

> And the problem with those was not that they did not have enough methods like Array, it was that they required a proxy

Look.  If we want to be able to do typechecking at `obj[index]` write time, we need a "proxy" in ES spec terms (or more precisely an object with non-default internal methods), because the default [[Set]] and [[DefineOwnProperty]] do not allow doing such a typecheck.  So _if_ we want to support this behavior at all, this is the way to support it.  Telling people "just use Array" corresponds to telling them "yeah, you don't want to do typechecking on set".  There are situations in which that's appropriate, and there are other situations in which it might not be.  In the end, whether it's appropriate or not is an API design decision.  There are some people in TC39 who think that any API that does such typechecking on set is automatically a bad API.  I understand where they're coming from, but I'm not convinced they're right.

Now Web IDL _already_ provides a mechanism for doing typecheck-on-set: indexed setters.  The same people who think typecheck-on-set is a bad idea also think that indexed setters are a bad idea.  This is not surprising.

> 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.)

To be clear, all I'm saying above is that we could have a simple Web IDL syntax for doing exactly this, so spec authors don't have to reinvent it from scratch (as @tabatkins notes we do just that for maplike/setlike).  The typed array bit is just about the exact behavior of the mixins involved: we would have them behave like the relevant functions on typed arrays do.


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