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

Enabling Subclassing of Reflect.Loader (major reorganization) #65

Merged
merged 8 commits into from
Aug 21, 2015

Conversation

caridy
Copy link
Contributor

@caridy caridy commented Aug 14, 2015

compiled spec from this PR

Changes:

  • Well-lnown Symbols
  • Loader Objects (loader base class definition)
  • Registry Objects (internal class definition for loader base class' [[Registry]] internal slot)
  • Module Objects (base class definition for Modules, former Reflective Module)
  • Browser Loader Objects (loader class for default loader instances implemented by browsers)
  • System.loader is an instance of Browser Loader
  • SitePackage was deferred (removed from the spec for now)
  • Use symbols to access hooks
  • Iterate over Registry (e.g.: for (let entry of System.loader.registry) {})
  • Avoid leaking internal temporary slots from registry entries. (more work to do here, for now, we expose state and statePromise instead of exposing all available internal promises for every past state)
  • Reflective Module -> Module Objects (Reflect.Module)
  • Backpointer from registry to the loader instance it belongs to.
  • Reflect.Loader.prototype.load() is now name and referrer driven.
  • annexes


Well-known intrinsics are built-in objects that are explicitly referenced by the algorithms of this specification and which usually have Realm specific identities. Unless otherwise specified each intrinsic object actually corresponds to a set of similar objects, one per Realm.

Within this specification a reference such as %name% means the intrinsic object, associated with the current Realm, corresponding to the name. Determination of the current Realm and its intrinsics is described in ES2015, 8.3. The well-known intrinsics are listed in Table X.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Italicize the "meta-variable" name, as in:

"a reference such as %name% means the intrinsic object, associated with the current Realm, corresponding to name."

(But don't italicize concrete names like %Loader% and %LoaderPrototype%.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@@ -899,13 +1030,11 @@ The browser loader has an extra internal slot:
<li>top-level packages consult \[[Site]]: <code>"jquery"</code>, <code>"ember/data"</code>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete this TODO since we're deferring site-packages

caridy added 2 commits August 21, 2015 10:46
…e dynamic module record, all the methods are just abstract operations.

<h4 id="create-module-mutator" aoid="CreateModuleMutator">CreateModuleMutator(module)</h4>
The Reflect.Module constructor is designed to be subclassable. It may be used as the value in an extends clause of a class definition. Subclass constructors that intend to inherit the specified Module behaviour must include a super call to the Reflect.Module constructor to create and initialize the subclass instance with the internal state necessary to support the Reflect.Module.prototype built-in methods.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change the end of this to "with the internal state necessary to integrated with loaders."

<p>
The site package system serves as a simple coordination mechanism for modest-sized applications, but it does not provide all functionality required of a full-fledged package management system. It is expected that development ecosystems will build around package management tools that deal with requirements outside the scope of this specification, such as version management and allowing multiple versions of a library to coexist with the same name.
</p>
<h4 id="Reflect.Module.prototype.constructor">Reflect.Module.prototype.constructor</h4>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove this -- there should not be a constructor property on the prototype (it can't have any properties).

dherman pushed a commit that referenced this pull request Aug 21, 2015
Enabling Subclassing of `Reflect.Loader` (major reorganization)
@dherman dherman merged commit 4894e16 into whatwg:master Aug 21, 2015
@caridy caridy deleted the loader-class branch August 21, 2015 18:30
@dherman
Copy link

dherman commented Aug 21, 2015

So much amazing work. Thanks @caridy, this is such great progress. <3

caridy added a commit that referenced this pull request Aug 21, 2015
@guybedford
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants