names for Loader constructor and default loader

[dherman]

Summary

Decide on names for two things: the Loader constructor and the default loader instance.

Background

Originally we had global System and Loader but that was when we expected System.get() to be a common use case. Once we worked out dynamic relative import, the default loader became a much more low-level API: it's meant for frameworks and loader customization logic, not for everyday use cases. So IMO giving it an attractive global name like System is inappropriate. Also, it was kind of competing with window, navigator, and process as Yet Another representation of the top level application state.

IMO Reflect.Loader is good for the constructor, but this still leaves open the question of where the default loader should live. Suggestions:

• another name in Reflect:
  • Reflect.System
  • Reflect.LOADER
• a static property or method of Reflect.Loader:
  • Reflect.Loader.DEFAULT
  • Reflect.Loader.current
  • Reflect.Loader.current()
• Reflect.Loader itself is both the constructor and the instance

My preference is a Reflect.Loader.current getter. ALLCAPS feels more appropriate for immutable constants like Math.PI rather than a mutable object, and a current() method feels like overkill for just accessing a singleton object. But I like the idea that it's conceptually associated with the Loader type but it's a static singleton instance.

Drawbacks

Systemjs already has named itself after System. But it's still a pretty cool name for the project, and this just gives it a more fun historical etymology. :)

[matthewp]

What's wrong with loader? It's descriptive enough to me.

I don't like current because I would expect Reflect.Loader.current to be the current loader in multiple loader environments. I would expect it to work the same as document.currentScript. We do need this capability, btw, but that's for another discussion.

I would strongly favor it being lower-case whichever name is chosen, it's too hard to forget it's not a constructor otherwise.

[domenic]

Reflect.Loader.default seems nice and wasn't mentioned.

[dherman]

I like Reflect.Loader.default a lot!

I think having Reflect.Loader and Reflect.loader both is too confusing, and Reflect.Loader.loader is just a little WAT.

[caridy]

I don't like current because it implies something that is changing overtime, which is probably not the case.

I think default its gonna be confusing for some people, I can imagine questions like: "is Loader.default to load things exported thru export default?"

I don't have a better suggestion. /cc @ericf

[matthewp]

I think having Reflect.Loader and Reflect.loader both is too confusing

Not to be argumentative, but why? It's pretty common to name constructor/instances in this way.

I don't hate default either. My only qualm would be that you tend to use the loader more than you realize so Reflect.Loader.default is a lot of typing.

[dherman]

Not to be argumentative, but why?

Argumentativeness welcome ;-)

It's pretty common to name constructor/instances in this way.

Fair point. I'm not sure I can justify my intuition. And maybe Realm will become the home of several realm-global variables: Reflect.realm, Reflect.global, Reflect.loader. I'm open to it.

[caridy]

I really like Reflect.loader (alongside Reflect.realm and Reflect.global). Mostly because it will be very friendly for people who don't care about loader customization, they will simply do Reflect.loader.site({...}); Reflect.loader.import(...);.

[arv]

Reflect.Loader.default or Reflect.defaultLoader.

I am also a bit concerned about Reflect.Loader vs Reflect.loader. Too easy to misspell.

[caridy]

Let me clarify my position, I want to see a very simple way to access the default loader without having to know that you can create more than one loader (as an advanced feature). Reflect.loader in lower case seems to be the simplest, and it aligns well with Reflect.global and Reflect.realm. From there, the question is, how to access the constructor? Reflect.loader.constructor maybe?

[matthewp]

@caridy The constructor is Reflect.Loader no? Reflect.loader instanceof Reflect.Loader should be true. We've made a mistake somewhere if not.

[dherman]

@matthewp I think he means the most derived constructor, in the case where the host environment decided to make Reflect.loader be an instance of a host-specific subclass of Reflect.Loader.

[matthewp]

@dherman Ah, yes, then as is normally the case, Reflect.loader.constructor will point to the most derived constructor. If you are working in an environment which overwrites Reflect.loader this is where the extension point would be.

[guybedford]

@dherman thanks for the SystemJS consideration, but don't let it be a drawback! Quite happy to have an etymological name.

[dherman]

@caridy I think your position is the strongest. There's plenty of precedent for lowercase singletons sitting next to their uppercased constructor (window instanceof Window, document instanceof Document), and in each case you can work with the singleton without needing to know how to use the constructor.

I think we should go with Reflect.Loader and Reflect.loader. I'll update the spec soon.