Written Proposal for "package" Keyword for ES20XX Imports

Logan Smyth loganfsmyth at gmail.com
Tue Feb 21 18:56:30 UTC 2017

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

On Tue, Feb 21, 2017 at 10:48 AM, Greg McLeod <cleod9 at gmail.com> wrote:

> 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.
> To elaborate, one of the biggest benefits I'd like to emphasize is the
> complete isolation of dependency resolution and actual module body
> execution.
> 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.
> On Tue, Feb 21, 2017 at 12:52 PM, Ryan Birmingham <rainventions at gmail.com>
> wrote:
>> 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?
>> -Ryan Birmingham
>> On 21 February 2017 at 12:27, Greg McLeod <cleod9 at gmail.com> wrote:
>>> Hi all,
>>> 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.
>>> Proposal can be found here:
>>> https://gist.github.com/Cleod9/7f73017905d124210ec8
>>> 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: https://as3js.org/demo/ ). 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#.
>>> 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.
>>> Any feedback would be greatly appreciated!
>>> Greg
>>> P.S. Screen-cap of a potential IDE future with packages:
>>> http://i.imgur.com/D5EGNUN.gifv
>>> _______________________________________________
>>> 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/20170221/9d8b9339/attachment.html>

More information about the es-discuss mailing list