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 {
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
Because it seems likely that people will want to use the System Loader but
also augment it with their own customizations. STILL benefiting from the
environment specific implementation details.
- Matthew Robb
On Mon, Jul 14, 2014 at 1:53 PM, John Barton johnjbar...@google.com wrote:
Why not
I suppose a system class effectively creates a store of the environment
loader hooks that can be trusted.
On 14 July 2014 10:53, John Barton johnjbar...@google.com wrote:
Why not something more like:
class RemappingLoader extends Reflect.Loader {
constructor(hooks, baseURL, paths) {
On Mon, Jul 14, 2014 at 11:11 AM, Matthew Robb matthewwr...@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
In the module system we issue
import {foo} from 'foo';
and the Loader computes an address, say foo.js, fetches the resource and
compiles it. If the content of foo.js has no dependencies, it is evaluated,
then the importer is evaluated. Yay!
Now suppose that foo.js defines a global value. Oh
Why not:
import {} from 'foo';
or
import * as f from 'foo';
This is assuming that there are no other desired exports -- if there
are, then the case is even easier.
Sam
On Mon, Jul 14, 2014 at 8:37 PM, John Barton johnjbar...@google.com wrote:
In the module system we issue
import
There is also:
import foo;
Yehuda Katz
(ph) 718.877.1325
On Mon, Jul 14, 2014 at 6:24 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
Why not:
import {} from 'foo';
or
import * as f from 'foo';
This is assuming that there are no other desired exports -- if there
are,
In the ModuleImport thread, I pointed out that the user experience gains
from default exports would be marginal. I thought it might be interesting
to put some numbers behind that claim, so I performed a rough analysis on a
sampling of NPM packages.
## Methodology ##
I compiled a list of the 500
Sorry, I was imagining a specific scenario without giving the specifics:
include 'foo'; // foo is conventional JS, not a module
I have written on global in a module, it works ok, but the goal was
specifically to mutate global with code written in a module.
Here I have given code, designed to
You could imagine a loader plugin that enabled:
import legacy:foo;
Which would evaluate the module in a script context.
Yehuda Katz
(ph) 718.877.1325
On Mon, Jul 14, 2014 at 9:20 PM, John Barton johnjbar...@google.com wrote:
Sorry, I was imagining a specific scenario without giving the
11 matches
Mail list logo
