Should we offer special proxies to arrays, maps, etc., for altering their views?

Low priority - this is more of a thought experiment than a must-have.

Containers do not fit well in the proxy model. Suppose I have an array _k_ which the "wet" object graph should see as _[A, B, C]_, and the dry object graph should see as _[A, D, E, C, B]_, where each capital letter represents an object or a proxy. Suppose also the wet object graph has access to the membrane and the dry object graph does not.

Looking up _k[2]_, or even _k.length_, then becomes quite a challenge in any object graph.

If the array comes from the wet graph, and the dry graph can alter it at any time:

- how would the wet graph safely store the changes that the dry graph has made?
- how would the dry graph safely show changes the wet graph wants to propagate?
- how would the wet graph hide changes from the dry graph that it doesn't want to propagate?

In these cases, the membrane can help a little by providing a 'manager' object for the container, provided the wet object graph _surrenders_ control of the original container to the membrane. The 'manager' object would live in a third, hidden object graph -- but its contents would come from one of the first two object graphs.

What would then happen is any operations on the proxies -- in the wet or dry graphs -- is then propagated to the special manager object actually tracking changes to the array. Then the proxies control what their respective object graphs see.

The problem with this approach is if the array comes from the _dry_ graph. Objects in the dry graph don't have access to the membrane, so they can't create a manager object. More to the point, the script providing the dry graph and the array owns the array - which means the wet graph can't just replace the array in memory with a proxy if the dry graph is running as pure JavaScript. This means changes to the array on the dry graph do not necessarily cross over to the wet graph in this model. Proxies can track changes to real objects they own, but in this case, the wet proxy doesn't own the dry array.

If the membrane or the wet graph is providing the "sandbox" execution environment for the dry side (say, by parsing and rewriting the script on the fly, or by running the dry code through a modified interpreter or JIT engine), then this can be fixed by redefining how the sandbox implements an array in the first place. But that's a big if, and far more complex than I know how to do right now.

The only way to make sure a dry array can have its changes tracked on the wet side, safely, is if the API of the wet object graph _completely assumes ownership_ of the array, and forces the dry side to accept a proxy. By defining it this way in the API, the dry object graph's users are responsible for being out of sync if they use their own array after passing control to the wet graph. (Internally, the wet object graph should pass ownership of the array to the membrane's hidden graph as described above and take ownership of a proxy to the array.)

Finally, this is just talking about arrays. There's other containers to worry about: maps and sets of both the strong and weak types, for starters.