Will it be possible to retrieve a loaded module's exports synchronously?

[John Lenz]

var exports = System.loader.registery.get('path/file.js');

On Wed, Feb 24, 2016 at 3:53 PM, Caridy Patiño <caridy at gmail.com> wrote:

> There is no such thing as a `key` in 262 (module spec). The `key` is a
> concept defined by the loader, and there it is not opaque.
>

I don't see where the value of the key/meaning of the key is defined.  Can
you be more specific as to what it is required to be?


>
> For my purpose the I would be interested in resolving the "name" so the
> module exports can be retrieved.
>
>
> Can you explain more? Resolving from where?
>

A script or a module.  If this isn't helpful, I'm unclear on what the
possible values for "where" are.


> The context matters for the resolution process, e.g.: the referral can
> define how to resolve a module identifier.
>

The context is user code, where the available "name" of a module would be
identical to what would be used in an import declaration.


> As for retrieving the module exports, you have to go thru the APIs that
> will guarantee that those exports are ready to be consumed, and those are
> the `import` statements, the `import()` calls, and
> `Reflect.Module.evaluate()`, you have no other way to access those exports
> in a way that is reliable.
>

"import", "import()" and "evaluate" all force a load and a wait.  Forcing a
load is distinctly not what is desired here.  I understand that a load
could be "under way" but if one wanted to wait they would simply call
"import()".


> Via the registry, you can attempt to inspect every module status in the
> registry, trying to access the namespace exotic object via
> ModuleStatus.prototype.module getter, but there is no guarantee that you
> get it, it depends on the current stage of the module in the pipeline.
>

I having a hard time here to trying to understand what I can say
differently to explain what I desire:  I need to know if a module is loaded
and ready, if it is I want the module exports immediately.



> /caridy
>
> On Feb 24, 2016, at 6:40 PM, John Lenz <concavelenz at gmail.com> wrote:
>
>
> On Wed, Feb 24, 2016 at 3:28 PM, Bradley Meck <bradley.meck at gmail.com>
> wrote:
>
>> In Node we can get the import path synchronously just from the parsed
>> module, as proposed API in
>> https://github.com/bmeck/node-eps/blob/es6-module/002-es6-modules.md
>> suggests. Can you clarify what you mean with
>>
>> > The "key" appears to only be resolvable asynchronously
>>
>> Which key? the path resolved from the source text?
>>
>
> From the spec the "key" appears to be opaque.  For my purpose the I would
> be interested in resolving the "name" so the module exports can be
> retrieved.
>
>
>
>
>>
>> On Wed, Feb 24, 2016 at 5:08 PM, Caridy Patiño <caridy at gmail.com> wrote:
>>
>>> I’m not sure what are you trying to do, but from within the module
>>> itself, you will have access to some metadata about the module, we have
>>> been chatting about `import()` and `import.<key>` as the imperative forms
>>> to import relative modules, accessing module’s metadata, and potentially a
>>> reference to the loader instance bound to the module (thru module status),
>>> but all that in up in the air.
>>>
>>> From outside, things are more complicated, you have access to the
>>> registry of every loader instance, you can walk each registry, and do what
>>> you please, but there is no guarantee that the module status that you’re
>>> looking for is accessible (they can be removed from the registry and still
>>> function).
>>>
>>> You should probably post this question on whatwg/loader repo.
>>>
>>> /caridy
>>>
>>> > On Feb 24, 2016, at 5:58 PM, John Lenz <concavelenz at gmail.com> wrote:
>>> >
>>> > Background:
>>> >
>>> > I'm trying to plan a migration to ES6 modules.  For interop with the
>>> existing systems in the short-medium term, I would like to be able to
>>> retrieve a loaded modules exports synchronously (basically a "get or fail").
>>> >
>>> > It looks like retrieving the exports synchronously is possible using
>>> the Registry object, however the registry requires that you have an
>>> appropriate "key".  The "key" appears to only be resolvable asynchronously
>>> which means the whole operation must async.
>>> >
>>> > Am I missing something?
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160224/135e79b4/attachment.html>