subclassability

[dherman]

Following on this subthread, the Loader class should be subclassable. In particular:

• the hooks should be inherited methods
• each hook should be called on<hookname> or <hookname>Hook (discuss which)

What else?

/cc @matthewp @guybedford @johnjbarton

[johnjbarton]

For the Traceur loader I defined abstract hook methods in Loader and implemented them in subclasses. (The code is krufty with older abstractions, but this bit seems ok).

I'm unsure why you need the modifier on or Hook. Mostly these things are verbs, eg fetch fetches so it seems like it already has its best name. These aren't notification events so on does not seem like a good match.

[matthewp]

I would agree with @johnjbarton as far as the on prefix.

I understand the concern that they are primarily used internally but as discussed in the previous issue they can be useful externally (at least some of them) so I don't think it's so bad to name them as they are currently.

@dherman are they any performance considerations for too much inheritance? Is having 20 levels of subclassing faster/slower than having 20 wrapper functions? Or am I underestimating modern js vms and this is a silly question.

[dherman]

@johnjbarton Sorry, this is carry over from the conversation in #7:

I mean I could just not worry about it; there are only four hooks. But there are is one name collision (resolve) and one "conceptual" collision (load vs fetch). And still the purpose of these is as hooks, not as external methods. I think I'm more comfortable with a name convention.

[domenic]

I have a naive questions. Maybe it will help clarify things?

Loaders have a lot of methods. If my subclass overrides import, lookup, uninstall, cancel, etc.---will those be called by the implementation sometimes? Or are they only called by author code?

[matthewp]

Yes, you absolutely should be able to override those. I see no difference between the hooks and those methods. import is one that is useful to override in some advanced scenarios.

[dherman]

@domenic The only methods that are triggered by the internal semantics of the loading process are the hooks. Those other methods (import, lookup, uninstall, cancel etc) are only triggered by user code.

@matthewp I believe both deep inheritance and deep wrapping can be expensive but I don't know enough about modern engines to compare them intelligently. I'm not super worried about this since I expect loader configuration to be a pretty top-level thing (comparable to, e.g., installing polyfills with a top-level script) so I don't expect to see lots of loader extension and configuration sprinkled throughout codebases.

[johnjbarton]

All of these hooks should be called on the order of once per module. Since the cost of processing each module is very large compared to any method invocation sequence, I vote for the solution that is the clearest for developers.

[caridy]

Solved by #65

[caridy]

subclassing is now supported via:

class MyLoader extends Reflect.Loader {}

hooks are now defined thru symbols:

System.loader[Reflect.Loader.fetch] = function (key) {
   // implement your custom fetch on the default loader
};

// or
let myLoader = new MyLoader();
myLoader[Reflect.Loader.fetch] = function (key) {
   // implement fetch on your custom loader instance
};