Re: [heycam/webidl] Introduce the observable array type (#836)

Is it necessary to make these types constructible? This doesn't seem necessary for the `additionalStyleSheets` use case or anything similar, assuming we are willing to get rid of assignability. With a properly mutable real array, there isn't much need to assign a new array, and doing so is a hazard. (It might be there are other use cases where constructing your own from script is desirable.)

Some thoughts about hooks. Do the `after` hooks provide anything useful that can't be done with `before`? Perhaps an alternate model is to think of `before` as an index setter that can throw or otherwise refuse. Then it can choose to do anything it wants either before or after actually updating the backing store. Maybe for JS-created ObservableArrays this makes sense, since we can't necessarily trust JS to satisfy the Array contract, thus needing hooks around the real setting; but in the case of native implementations, the implementation may want to simply replace the real setting. This would be more natural. Of course, if it was done that way, the implementation would want to replace getting as well. Not sure why this more complex way. Does it help simulate some aspects of array realness that can't be simulated otherwise? Is it solely for the benefit of JS (where a JS callback can't otherwise be trusted to fulfill the Array contract)? A way to make things work in JS without separate before and after callbacks would be to have singular callbacks which get passed a function that performs the operation on an underlying backing store; JS can choose to call it or not.


-- 
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/836#issuecomment-579121271