`idMap` is a strange property; it's only populated with nodes which had a given `id` *at the time of parsing*, and said nodes continue to be referenced even if the node is removed from the document. I have yet to find a way by which nodes can be deleted from `idMap`.
It also takes expandos, so this has to be a new retained object on the XML document. I originally considered not creating *another* `Object` impl and populating a regular `ScriptObject` with nodes, but that meant we couldn't lazy-instantiate their AVM1 side counterparts. Boo. :/
This requires some subclassing nonsense to be able to smuggle a self-reference into `SuperObject`s. When successfully smuggled, all calls to `call` will be invoked with the `super` object as `this`. This allows constructor chaining to work.
Note that not all `Object` trait methods are implemented on `SuperObject`, so things like `delete this.x` in super constructors will randomly fail. This should be fixed.
We implement `super` by way of a new `Object` impl which wraps arbitrary objects with a modified prototype chain. Specifically, the lowest layer of the prototype chain is omitted. This new `SuperObject` script is composable: a chain of two `SuperObject`s will go two levels of inheritance upwards while still maintaining non-prototype property access.
In Flash, this also at least claims to halt ActionScript execution on the movie. No such implementation of AVM poisoning currently exists in Ruffle, primarily because it's unclear what gets poisoned and implementing some of these options isn't yet possible:
1. AVM (e.g. all movies) - we would need to make the AVM fail silently in this case. This is the most straightforward way to poison the movie, but I'm not sure if this is how Flash actually does it, or if it poisons...
2. Movie - the current structure of movies is incompatible with adding arbitrary data to them. We need to merge `moviefetch` in before we can attach data to loaded movies.
3. MovieClip - this would also be implementable but has problems. How do child MovieClips know that their parent has been poisoned, or vice versa? What if a movie clip is loaded from one movie and moved into another?
As a result, I have decided to hold off on implementing recursion poisoning until I know where it's supposed to go and how to implement that.
While I don't expect every host object to implement it correctly, this also gets rid of a lot of unnecessary `unwrap` calls that would allow a poorly-written Flash file to kill the interpreter.
Note that host objects that do so will *not* have access to their standard representation from within member functions - you will need to extend the interface to accomodate for them. This is due to long-standing limitations with type IDs and downcasting with types that bear lifetimes - it's entirely an unsafe operation and exposing such a facility to safe Rust is unsound. However, this will at least let us separate out several things from ScriptObject that don't need to be there for the time being.
`Object::function` now returns a pre-allocated function object. You may supply it an explicit prototype to have it linked into the function object (which is why we have to return a cell).
The previous behavior had an oversight: if you tried to set a variable with the same name as an in-scope property, it would always try to overwrite that property. This can fail silently and doesn't match with Flash Player behavior. Now, an attempt to overwrite a read-only property is instead correctly rejected so that it can be defined in local scope.
This type explicitly signals if an immediate value is to be returned, if a value is to be returned on the stack, or if no return value is to be generated. Holders of a `ReturnValue` can also use `and_then` to schedule a `StackContinuation` to be executed when and if that value is ready.
`StackContinuations` now yield `ReturnValues` as well, so they have a moderate level of composability. For example, if you need to get a property from an object and push it on the stack, you can return the result of calling `get` directly and the machinery ensures it eventually gets there.
This involved yet another macro, `and_then!`, to avoid a ridiculous amount of duplicate code. It calls a continuation whenever it's value is ready, even if the value resolved on the Rust stack.
`locals_into_form_values` does not currently support this. It skips any property that does not resolve on the Rust stack. Future work is required to resolve this.
David Wendt