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

> I keep getting told that it's a legacy feature that no one should use.

I think you are being told wrong.

> It's silly that we have to do `[].slice(document.querySelector(...)).map(...)`

You don't have to do that if you use [ArrayClass].  Yes, I know that's claimed legacy too.

That said, if you use [ArrayClass] and then use slice() or map() you will get an Array, not your thing.  If you want to get your thing from slice() or map(), then you really do need an Array subclass, and then you can't control writes to it.  Well, mostly.  What ES allows you to do is to have your object be a Proxy whose target is an Array, and then you can still control construction of slice/map return values, plus of course you can control writes, because now you have all the proxy machinery at your disposal.

I know there are concerns proxy performance being a problem, but we really can't have it both ways as things stand: either we have fast indexed writes that just blit memory and the JIT can optimize all it likes, or we have indexed writes that run some sort of verification code that the JIT knows nothing about conceptually and then we end up taking slow paths, unless the JIT is explicitly taught about this verification code and what its invariants are.  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.

So in principle we could spec something like the maplike/setlike in the spec (which delegate to ES Map/Set after doing some sanity checks), by defining the object as a proxy, with an Array target, with Array.prototype on its proto chain.  I'm pretty sure that will do the "right thing" when that object is `this`.  What it does when the object is an argument, I'd have to think about.  It's not clear to me whether this is a thing people want.

We could also try lobbying TC39 to have more of a carve-out in ArraySpeciesCreate for exotic objects that quack like array subclasses but aren't really, just like they already have for Proxy.

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?

Is the point that you want IDL to predefine these methods for you, instead of you defining them yourself, with whatever semantics you want?  (I'm not saying this is an unreasonable desire; just trying to figure out what the actual constraints are here.)



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