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.
On Tue, Feb 21, 2017 at 10:48 AM, Greg McLeod <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
