instantiate() deps list
johnjbarton at google.com
Thu Aug 21 08:46:13 PDT 2014
The Loader instantiate() function is described:
Based on that description I assume that the 'deps' property returned by
instantiate() meant "dependencies" that would be loaded by the loader. That
is, one can leverage the dependency traversal from a custom loader. But
it's not possible to do this.
Otherwise, the instantiate hook must return an eventual
instantiationRequest object. An instantiateRequest object has two required
properties. The value of the deps property is an array of strings. Each
string is the name of a module upon which the module identified by
loadRequest has dependencies. The value of the execute property is a
function which the loader will use to create the module and link it with
its clients and dependencies. The function should expect to receive the
same number of arguments as the size of the deps array and must return an
eventual Module object. The arguments are Module objects and have a
one-to-one correspondence with elements of the deps array.
The module is evaluated during the linking process. First all of the
modules it depends upon are linked and evaluated , and then passed to the
execute function. Then the resulting module is linked with the downstream
However it turns out that the names in 'deps' are simply fetched and passed
back to instantiate(). They do not enter the dependency analysis.
To give a concrete example, if A depends on B depends on C and
instantiate() is called with A, it can't simply return a deps list with
"b". It has to perform the entire dependency analysis of A and ensure the
tree is loaded. Simply returning 'b' as a deps value will result in an
execution sequence like A, B, and then C, not the order C, B, A one would
expect from a dependency analysis.
I'm sure there is a good reason for this behavior but it should be clearly
called out in the spec.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss