Re: [heycam/webidl] Remove [LegacyArrayClass] (#291)

> It "works fine" by requiring a proxy to intercept all numeric property accesses

Well.... on a conceptual spec level, true.  Engines _can_ optimize things to have an internal hook like the one you describe if they want to.  That said, the various issues with it that I think people object to would be the same with such a hook.

> As such, it's not a solution we want to use in general.

What are the specific concerns with using it, other than "makes the spec author feel icky"?

> My use-case is dead lists

Dead in the sense that you set it up, hand it to someone, and never look at it again?

In that case, why not just use Arrays or an Array subclass (ignoring for the moment the lack of easy way to express it in IDL)?  I feel like I'm missing something...

> Easy to define that the auto-defined versions of these methods return values of the same type

That doesn't necessarily make sense for map, note.  If you have a list of Foo objects and call map on it with a function that returns booleans, you get a list of booleans.  Whether it makes sense to still represent it by the same list type kinda depends on what operations are defined for your list.  Not an issue for filter(), of course.

> but I guess the problem is live collections

Sure.  We could do the map() thing as an opt-in via some IDL syntax and only non-live collections would define it.  Or one of your suggestions.

> Tho just using an Array subclass still leaves you with the question, raised by Boris, of what the result of calling obj.map() is

Right, you have to define it.

> if this is grabbing the Array.prototype.map function, then your callback result isn't typechecked, and the method returns an ordinary Array

Not quite.  You're right that the callback result is not typechecked.  What it returns depends on your .constructor value and its Symbol.species property, etc.

That is, ES `Array.prototype.map` can return an object with the proto chain the "this" value chooses, but it's still a JS array and anyone can stick anything into it, just like any Array subclass instance.

> Same with filter, and any of the other Array methods that return an Array.

`filter` is simpler, again because it uses existing values, so won't mess up your element types for you.  The created thing again depends on your .constructor and whatnot.  See https://tc39.github.io/ecma262/#sec-array.prototype.filter step 5 and the https://tc39.github.io/ecma262/#sec-arrayspeciescreate rabbit hole.



-- 
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/291#issuecomment-283496271