<div dir="ltr">I don't have tons of comments on the proposal as a whole, but I do think there may be confusion about ES6 imports. Imports are resolved and processed and modules linked before any execution of the module body takes place. I can't tell from your description if you are reading that differently.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 10:48 AM, Greg McLeod <span dir="ltr"><<a href="mailto:cleod9@gmail.com" target="_blank">cleod9@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks Ryan. I think there would be a bit of an issue with introducing dictionary support alone in that it does not provide a new way for the language to define where modules actually live in the application itself as opposed to the file system. This misses out on the benefits the package keyword could provide. "package" should impose some limitations on the top-most scope 
of a module to facilitate the ability to define the packages before actually
 executing a module's body.<br><br>To elaborate, one of the biggest benefits I'd like to emphasize is the complete isolation of dependency resolution and actual module body execution.<br><br></div><div>The package keyword in my proposal would allow you to arbitrarily say "here's the complete structure of my app, all dependencies already resolved" and subsequently take action on it after it has been fully loaded into memory in its entirety. Augmenting existing import syntax cannot allow this since the core body of each module is being executed amidst the dependency graph being resolved as each "import" is encountered by the interpreter.<br><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 12:52 PM, Ryan Birmingham <span dir="ltr"><<a href="mailto:rainventions@gmail.com" target="_blank">rainventions@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I like the idea you're working from here, it seems to partially resemble header files. I'm not sure if a package keyword is needed though; couldn't you accomplish the same thing with just adding dictionary support and an optional alias parameter to import/export?</div><div class="gmail_extra"><br clear="all"><div><div class="m_5908789385669403926m_7711791218089113669gmail_signature" data-smartmail="gmail_signature">-Ryan Birmingham<br></div></div>
<br><div class="gmail_quote"><div><div class="m_5908789385669403926h5">On 21 February 2017 at 12:27, Greg McLeod <span dir="ltr"><<a href="mailto:cleod9@gmail.com" target="_blank">cleod9@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_5908789385669403926h5"><div dir="ltr"><div>Hi all,<br><br></div><div>Back in 2015 I was working on a proposal for the "package" keyword, but stopped prematurely as ES6/ES2015 had already been shipped. Since then I've been occasionally iterating on it anyway in order to flesh out my ideas with how it could fit with the new import syntax. I wanted to share with the mailing list to get some feedback on it, as well as help facilitate some of the discussion regarding future import syntax.<br><br></div><div>Proposal can be found here:<br><a href="https://gist.github.com/Cleod9/7f73017905d124210ec8" target="_blank">https://gist.github.com/Cleod9<wbr>/7f73017905d124210ec8</a><br><br> I should note that a lot of this is derived from an ActionScript to JavaScript proof-of-concept transpiler I wrote a few years back. (Live demo: <a href="https://as3js.org/demo/" target="_blank">https://as3js.org/demo/</a> ). I believe this type of package syntax/behavior has already been possible since ES5, although I have yet to find any proposals for the keyword that resemble that of battle-tested languages like Java/C#.<br><br></div><div>I think there are a lot of time-saving qualities that packages could provide for bundled JS applications we have yet to explore, and it could even open the door to a JS standard library. Even if this doesn't go anywhere I certainly hope by making this proposal public it will be a useful for reference for what is possible in the current state of affairs.<br><br>Any feedback would be greatly appreciated!<span class="m_5908789385669403926m_7711791218089113669HOEnZb"><font color="#888888"><br></font></span></div><span class="m_5908789385669403926m_7711791218089113669HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="m_5908789385669403926m_7711791218089113669HOEnZb"><font color="#888888">Greg<br></font></span><br></div><div>P.S. Screen-cap of a potential IDE future with packages:<br><a href="http://i.imgur.com/D5EGNUN.gifv" target="_blank">http://i.imgur.com/D5EGNUN.gif<wbr>v</a><br></div><div><br></div></div>
<br></div></div>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>