Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Details] Loader and Registry interleaves #73

Closed
caridy opened this issue Aug 21, 2015 · 2 comments
Closed

[Details] Loader and Registry interleaves #73

caridy opened this issue Aug 21, 2015 · 2 comments

Comments

@caridy
Copy link
Contributor

caridy commented Aug 21, 2015

This is a follow up on the discussion related to PR #65

Participants: @dherman @caridy @guybedford

As part of #65, we have rearranged the internals of the loader, and its registry. As a result, we now have two separate entities with the following responsibilities:

  • Loader provides a public api to interact with modules (via their names and their referrers), and it will be reflective to what you can do with the local loader from within a module.
  • Registry provides low level api to interact with the registry of modules (via their keys), and it is bound to a loader instance.

But, there are two conflicting perspectives on the loader/registry responsibilities:

  • perspective 1: the loader provides the high level interface and the registry provides the low level interface
  • perspective 2: the loader provides loading pipeline and the registry stores the state
    it almost works for both perspectives

Few more notes:

  • [[Registry]] internal slot is created and initialized in the constructor of the loader.
  • It is not allowed to have multiple loaders sharing the same registries.
  • a .registry getter in a loader instance will give you access to the corresponding registry (e.g.: let registry = System.loader.registry;)
  • the registry has a backpointer to its loader ([[Loader]] internal slot) in case of side effects during the interaction with the registry (e.g.: System.loader.registry.provide() or System.loader.registry.error())

As a result of this separation, we have to separate the loader API:

Loader:

  • Reflect.Loader.prototype.import(name[, referrer])
  • Reflect.Loader.prototype.resolve(name[, referrer])
  • Reflect.Loader.prototype.load(name[, referrer[, stage]])
  • get Reflect.Loader.prototype.registry

note: load is now a primary use case to pre-fetch, and provision a module from a referrer.

Registry:

  • Registry.prototype @@iterator
  • Registry.prototype.lookup(key)
  • Registry.prototype.install(key, module)
  • Registry.prototype.uninstall(key)
  • Registry.prototype.cancel(key)
  • Registry.prototype.provide(key, stage, value)
  • Registry.prototype.error(key, stage, value)

note: all these methods are low level, and driven by a key.

@caridy
Copy link
Contributor Author

caridy commented Aug 21, 2015

Solved by #65

@caridy
Copy link
Contributor Author

caridy commented Aug 21, 2015

@caridy caridy closed this as completed Aug 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant