Make Loader.prototype.define and Loader.prototype.module set step to 'fetch' if options.address set

[guybedford]

This would allow the:

  <module name="name" src="source">

Module loading scenario, if it is going to be supported.

Similarly for the anonymous analog:

  <module src="source">

[probins]

related to this, there's a contradiction with 1.6.3.18 which says that module() and define() don't need to be fetched. Is there a difference between define() with an address option and load()? If not, then perhaps it would be better to remove address option from define(), and say that define() is the equivalent of <module name="xx"> and load() is the equivalent of <module name="xx" src="...">.

[dherman]

@guybedford I can see that the API is making the correspondence to HTML confusing, sorry! The correspondence is:

• <module name="..." src="..."> : loader.load()
• <module name="...">...</module> : loader.define()
• <module>...</module> : loader.module()
  Adding the address to loader.define() is only for the purposes of propagating it through as part of the metadata, not actually for driving through the loading pipeline differently.

This skinning of the API is obviously confusing, because it's not clear how it corresponds to the features it reflects. Jason and I are going to noodle on skinning the API better to make these correspondences clearer.

[johnjbarton]

How about something like loader.module(name, source, options):

• <module name="..." src="..."> : loader.module(name)
• <module name="..."> ...</module> : loader.module(name, source, {})
• <module>...</module>: loader.module(null, source)
  Only if you want to add options to but not source is it awkward, but that ok, you'll have to look up the docs to get the options set correctly anyway.

[guybedford]

@dherman ok that makes much more sense, thanks for clarifying! Closing this issue in some attempt to keep things organised.