System as a SystemLoader class

John Barton johnjbarton at google.com
Mon Jul 14 10:53:33 PDT 2014


Why not something more like:

class RemappingLoader extends Reflect.Loader {
  constructor(hooks, baseURL, paths) {
    super(hooks);
  //...
  }
  fetch(load) {
  // ..
  }
}
Reflect.global.System = new RemappingLoader(Reflect.global.System,
   process.cwd() + '/', {'*': '*.js' });

The main differences here are:
  1) This already works,
  2) Use std Loader not System.constructor,
  3) Don't attach baseURL to loaderConfig, since the loaderConfig is
documented in the std.

(System is already an instance of Reflect.Loader so I'm unclear on why we
need the change you suggest).

The biggest hole I see in my example is the use of Reflect.global.System as
the value for the loader hooks. What I want to say here is "This platform's
built in loader hooks", not "The loader hooks some random other package
wrote onto System".

jjb




On Mon, Jul 14, 2014 at 10:39 AM, Guy Bedford <guybedford at gmail.com> wrote:

> Currently if I want to subclass the System loader I need to do something
> like -
>
> var newLoader = new Loader(System);
> newLoader.fetch = function() {
>   // ...
> }
>
> Effectively we're monkey-patching, which isn't pretty.
>
> It would be nice to be able to do:
>
> class newLoader extends System.constructor {
>   constructor(loaderConfig) {
>     this.baseURL = loaderConfig.baseURL;
>     // ...
>   }
>   fetch: function() {
>     super.fetch
>   }
> }
>
>  In order to allow this, we would need to first define a SystemLoader
> class, and make System an instance of it.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140714/d8b7a336/attachment.html>


More information about the es-discuss mailing list