System.import()?

[Michael McGlothlin]

I'd like to see a general horn-clause style dependency resolution system built into JavaScript functions and see that applied to dynamic loading. Then the same system could be used to executing async operations smoothly, logic programming, etc. Something smart enough to resolve all the relationships from simple rules and lazy load the required bits as soon as possible. I've done that with running async code and it makes more sense to me than Promises.


📱 Michael McGlothlin

> On Aug 19, 2015, at 5: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/520a429c/attachment.html>