Re: [heycam/webidl] Introduce the observable array type (proxy-based) (#840)

This is ready for another round of review. I updated to override all the traps, and store the data in the backing list, not the indexed properties of the target. This is more verbose on the IDL specification side, but has a number of advantages:

* Better for specification authors using this, as now they can refer to and manipulate the backing list using any operation, and it will be reflected appropriately.

* The algorithms are more obviously correct now, as they each special-case length and indexed properties, then pass along everything else. Before, when we were reusing a lot of the array infrastructure, it was less obvious what would work, since you'd have to know facts like "setting length calls [[Delete]] on the deleted properties" or "defining a property with no [[Value]] in the descriptor will eventually do nothing if we pass it through".

* Closer to how implementations would likely work, if they piggybacked off of legacy platform object infrastructure. I.e. this more obviously meets @bzbarsky's idea of

    > Is the proposal black-box-identical to having a proxy that returns true for IsArray via "magic" (only possible in ES spec terms if target is an array, but engines may have other ways of doing the magic), returns Array.prototype from getPrototypeOf, stores a list of IDL values, not an array of ES values, and defines all the proxy traps appropriately to work with that list of IDL values. Or, still black-box-identically, have an IDL object with an indexed getter and indexed setter, but returning true from IsArray and with Array.prototype on the proto chain.

-- 
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/pull/840#issuecomment-589283290