You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 3, 2019. It is now read-only.
Our current implementation of ApplicationDomain is mostly stubbed. We need a proper implementation for #341, having at least the following characteristics:
Manages a set of AS3 classes available to scripts.
Activates said set of classes on being activated, itself.
Deactivates said set of classes on being deactivated, itself.
entails changing all the global object's references to all namespaces and global AS3-visible properties to point to the domain's own versions of them. 3. entails removing them from the global object. Note that it is not enough to rely on the next active domain installing its own active classes: it might have a smaller set of them, leaving some of the previous domain's classes installed.
The described behaviour very roughly matches sibling domains as described here. To fully support ApplicationDomain, we also need to add support for sub domains, which mostly means adding support for lookup of classes through chains of domains, where a class is looked up in the current domain first, and, if it's not found, lookup traverses the list of parent domains until a definition is found or the list is exhausted. If we were to do that right from the beginning, we might get away with only instantiating one version of the System Domain. Or we might not, depending on our ability to deal with per-instance state of the system builtins.
The text was updated successfully, but these errors were encountered:
ApplicationDomains should work, as well as child domains. The main part to implement is to reduce the number of references to global object properties that are baked in compiled code.
Our current implementation of ApplicationDomain is mostly stubbed. We need a proper implementation for #341, having at least the following characteristics:
The described behaviour very roughly matches sibling domains as described here. To fully support
ApplicationDomain
, we also need to add support for sub domains, which mostly means adding support for lookup of classes through chains of domains, where a class is looked up in the current domain first, and, if it's not found, lookup traverses the list of parent domains until a definition is found or the list is exhausted. If we were to do that right from the beginning, we might get away with only instantiating one version of the System Domain. Or we might not, depending on our ability to deal with per-instance state of the system builtins.The text was updated successfully, but these errors were encountered: