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

> That's all independent of whether we have a [] hook; the presence of such a hook would cause the JIT to deopt just as much as being a full-blown proxy does, until special fast paths are added there.

Presumably it would deopt into the same speed as any normal method call, yes?  If that's the case, then I can stop worrying about this, and just use it.  I've been given the impression, tho, that it actually de-ops to something substantially slower than an ordinary method call.

> As far as your goals go, what do you consider reasonable semantics in this case for map, foreach, filter, slice, etc? Or rather, do you consider the semantics of the corresponding Array.prototype methods to be unreasonable in this case, and if so in what way?

The Array.prototype semantics are "unreasonable" only in that they assume the object is an Array (with no arg-checking) and act accordingly.  I want a type-restricted Array, with relatively obvious semantics (at least, other languages handle this pretty consistently):

* forEach doesn't matter, it just consumes the Array-like and outputs nothing. It's fine as-is.
* map should throw if the callback's return value doesn't type-check, and it should return a value of the original class
* filter should return a value of the original class
* etc.

In general, the semantics are "return an object of the same class, and if mutations/additions happen, typecheck and throw if necessary".  In keeping with general WebIDL semantics, they should probably also brand-check their `this` value to be of the proper class, but I don't actually care about this; it should assume whatever answer is better for implementations.

> One thing we could do is have some way in IDL to just opt into behavior similar to what typed arrays have in ES. Those are not array subclasses, but have various things like slice/map/filter/etc defined on them, with special typed array semantics that are not generic unlike the Array versions. They perform coercion (which can throw) on write. This sounds like more or less what you're asking for, right?

I'd have to study the details, but the surface gloss you're giving me here sounds :+1:.

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