System.import()?

[Matthew Robb]

I think a nice syntax would be allowing you to CALL import as a function
from within function bodies to get contextual dynamic loading that is still
SORT OF analyzable. It would also be nice if these import calls could
SOMEHOW work like async function calls and not require direct interaction
with a promise or callback. But I just work up so I may still be dreaming.


- Matthew Robb

On Wed, Aug 19, 2015 at 6:46 AM, Guy Bedford <guybedford at gmail.com> wrote:

> It's great to see more interest in dynamic loading here.
>
> The contextual loader may be worth considering as a focus here - this is
> the special contextual loading syntax to effectively provide a scoped
> System.import call whose referrer is locked to the current module (`import
> module from this` as Dave has put in the roadmap, but I'm not sure what the
> exact syntax proposal is).
>
> This is the equivalent of the dynamic require in Node.
>
> As syntax it seems that would be in ECMA-262, and also might avoid the
> async Promise issues to share with Node as it can be entirely
> implementation-specific.
>
> Having a spec for this syntax would certainly be beneficial as it would
> immediately enable transpilers and module loading environments to then
> provide the dynamic loading feature, without other specification effort
> necessary.
>
>
> On Wed, Aug 19, 2015 at 10:38 AM Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>
>> There are ways for syncing promises for Node compatibility, although they
>> all lie in C++ land. Similar has already been done with Node callbacks.
>>
>> https://www.npmjs.com/package/sync
>>
>> (You could also spawn a thread, block for a message, and join it with the
>> promise result from a C++ callback from a thenable.)
>>
>> On Tue, Aug 18, 2015, 18:06 Bradley Meck <bradley.meck at gmail.com> wrote:
>>
>>> The problem is timing; WHATWG uses promises, which Node cannot use due
>>> to existing code bases on npm + potential mixing w/ `require`. This causes
>>> time discrepancies and would mean different actions depending on how
>>> exactly hooks are specced out. Node does not want to prevent async loading
>>> on the browser, and the WHATWG loader does not want to cause breakage in
>>> Node.
>>>
>>> On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff <
>>> jason.orendorff at gmail.com> wrote:
>>>
>>>> On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck <bradley.meck at gmail.com>
>>>> wrote:
>>>> > This would assume they can support the transformation hooks to do
>>>> things
>>>> > like load coffeescript etc. right now, which is the main contention
>>>> point.
>>>>
>>>> It is a perfectly ordinary occurrence in software to ship some
>>>> capability at one point, and ways of customizing that capability
>>>> later.
>>>>
>>>> -j
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> 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/20150819/b2046da4/attachment.html>