mutable System.loader

[dherman]

To support not only subclassability (see #35) but the ability to use a custom subclass as the built-in loader, should we allow System.loader (according to the discussion in #34 this seems to be the best name for the default system loader to live in) to be mutated?

The reason to allow this is that it's more expressive: if you have custom loader logic defined in a subclass, you can't use that simply by modifying the hooks of System.loader; you need to replace it with an instance of that subclass.

There are a couple of subtleties, however:

• It's not likely to be possible to replace the registry of one loader with another (even when we expose the registry as an object, its methods have to be bound to its owning loader in order to consult the hooks). Instead, replacing System.loader would require you also to populate the new loader's registry with any entries you want to share from the old one. (At a minimum this can be done by iterating over the old registry (see Iterating over the registry #17) and copying the entries in. Alternatively it should be possible to define subclasses with "chaining" logic that allows some lookups to delegate to another loader.)
• Implementors will probably prefer that none of the HTML semantics requires directly triggering a property get. I don't have a super crisp explanation for why that is, but I suspect there could be security worries when we do things like that, or possibly performance issues. However, this seems pretty easily managed as long as we define all the API's in terms of getter/setters or methods that consult internal properties. So for example the %System% object would have a [[Loader]] property, for example, with System.loader being a getter/setter pair.

[jolyndenning]

+1 for this feature. Is my understanding correct when I say that without this feature, the import keyword could never refer to a custom loader, but instead would always refer to %BrowserLoader%?

[caridy]

@joeldenning that is correct. Without the ability to set System.loader to a new loader instance, we have only two choices:

• AOP on System.loader's hooks to control System.loader.import() calls.
• Use a different abstraction to rely on a custom loader, instead of using System.loader.import().

[jolyndenning]

@dherman Could you help me understand your second bullet point? I'm pretty new to reading through these types of specs and don't understand what you meant by "HTML semantics triggering a property get."

[caridy]

@joeldenning this is a question of whether <script type="module"> will have rely on a mutable System.loader or not, and what are the implications of that from the security point of view since the engine will have to access something from user-land. Essentially, how the semantics of the script tag type=module will trigger a property get on System to access the loader instance that should be used. If System.loader can't be mutated, the engine can resolve this by keeping in internal slot for the default loader and there is not need to trigger a property get.

[caridy]

note: I don't think there is precedent for the property get triggered by HTML semantics, but I might be wrong.

[domenic]

Yeah, this is an area fraught with danger, as custom elements shows. But it should be possible to make this as palatable as custom elements, e.g. by deferring all such property gets until a later queued task, instead of having them happen during parsing.

[jolyndenning]

Would document.cookie be a precedent? It is a userland-writable property that the engine already has to look up whenever it sees a <script> tag in the dom. For example, consider the following code:

document.cookie = 'joel=denning; ' + document.cookie

var el = document.createElement('script')
el.setAttribute('src', 'source-file.js')
document.body.appendChild(el);

I just verified in Chrome that joel=denning is indeed sent as part of the cookie in the HTTP request.

[caridy]

ha, that is a good example. thanks @joeldenning.

[jolyndenning]

In regards to the first bullet point in @dherman's original post, is there any feature there that could not be implemented in userland (especially now that, as of #65, a loader's registry is iterable)?

In other words, is there any advantage to having the host environment do "loader chaining" instead of userland code?

[caridy]

@joeldenning the question here is how <script type="module"> can rely on a custom loader vs custom hooks. If what you have in mind is to completely drop the support for <script type="module"> in favor of imperative code in userland, that will imply that you will have to have at least one "legacy" <script> tag to invoke the loader, that's the part we are trying to mitigate.