forbes at lindesay.co.uk (2014-07-16T22:39:09.529Z)
Matthew Robb wrote: > Because it seems likely that people will want to use the System Loader but > also augment it with their own customizations. Yes, that is what I did below. > STILL benefiting from the environment specific implementation details. Yes, we need ways for custom loaders to define which implementation they extend. Some may choose to extend "whatever random System was loaded last"; the rest of us would like to choose to extend definite testable Loader instance. I suppose we can have LoadMeFirst code and all that but really this is ES6: can't we do better?
On Mon, Jul 14, 2014 at 11:11 AM, Matthew Robb <matthewwrobb at gmail.com> wrote: > Because it seems likely that people will want to use the System Loader but > also augment it with their own customizations. > Yes, that is what I did below. > STILL benefiting from the environment specific implementation details. > Yes, we need ways for custom loaders to define which implementation they extend. Some may choose to extend "whatever random System was loaded last"; the rest of us would like to choose to extend definite testable Loader instance. I suppose we can have LoadMeFirst code and all that but really this is ES6: can't we do better? jjb > > > - Matthew Robb > > > On Mon, Jul 14, 2014 at 1:53 PM, John Barton <johnjbarton at google.com> > wrote: > >> 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 >>> >>> >> >> _______________________________________________ >> 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/ff38eb09/attachment.html>