- From: Boris Zbarsky <notifications@github.com>
- Date: Fri, 11 Oct 2019 11:24:18 -0700
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Friday, 11 October 2019 18:24:20 UTC
> I think one route toward fixing this is using the classes in #796 to completely replace all FrozenArray<> usage. So in that world, things that currently have readonly `FrozenArray` attributes would return either `ReadonlyArray` or `ReactToAbleArray`? And current code that uses the attibute setter, assuming any such APIs are shipping, would be modified to modify the `ReactToAbleArray`? > Here's a stab: This seems pretty reasonable to me, with the additional note that the "create and freeze" step is not observable, and could be done lazily on get, as far as I can tell, as long as the global used for the creation can't change over time. In either case that global should be defined, presumably to the relevant global of the object involved. We _could_ consider having mutations to the backing infra list automagically invoke "reset the frozen array value" to the new value, so spec authors can mutate it directly. That does involve some slightly weird action at a distance that might be non-obvious when reading and implementing a spec... I don't have any great ideas for improving that so far. -- 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/810#issuecomment-541172783
Received on Friday, 11 October 2019 18:24:20 UTC