Re: [heycam/webidl] A new approach to array-ish classes (#796)

> The intention is basically to allow these to be usable by web developers in the same way as they would be for spec authors.

Ah, ok.  The details of what those callbacks get we should think about, but the general idea makes sense.

> I think the main other benefit is providing a clear path forward for future cases in the platform. 

Right, makes sense.

If we wanted typed readonly arrays, by the way, we could roll all this up into a parametrized declaration (a la `iterable`) that creates an anonymous indexed getter, changes the proto chain, adds a constructor, adds `@@isConcatSpreadable`, etc.  One difference there is that we would also allow adding other methods on the array type; whether this is a benefit or a drawback is an interesting question.

I guess this is basically the `legacyarraylike<T>` possibility you mention above?

> However, I'm unsure how much appetite there is for upgrading existing APIs,

I, personally, would _really_ like it if the return value of `querySelectorAll` did not suck to use...  I agree that there are compat risks there, though, and it would have to be done carefully.  But I think the benefit would be quite worthwhile if we can manage it.

Unfortunately, for legacy APIs we may be able to do things like change the proto chain but not add `@@isConcatSpreadable` or the other way around or whatnot...  That sort of argues for having separate primitives for these pieces if we want to address legacy APIs, but we can create the new thing first as a monolith and then think about refactoring it too as use cases come up.





-- 
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/796#issuecomment-531806617