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

I have to admit to being pretty confused at this point.

If someone wants typechecking on set, we have a mechanism for that: an interface with an indexed setter.  That's a hook that catches sets with integer-named property sets and does something.  That is its whole point.

That object won't be an Array, obviously, because it has totally different semantics from Array, both in terms of indexed sets and in terms of length-mutation (it probably either disallows length mutation, or allows it but doesn't use `undefined` as the value for newly added entries).  That's all fine: the desired semantics are explicitly different semantics from ES Array.

Now whether this is what web authors want, I can't tell you.  AWB would claim that they _want_ the "typecheck as late as possible" behavior, and that this is faster because you only do the typechecks when you really care about them and not at every API boundary, and further that any typechecks should be duck-typing, not branding.  There are obviously philosophical differences about that...

But the point is, we have a tool for getting the observable  behavior being described.  If that's the behavior we want, and we have a tool for it, why not just use the tool?

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