Written Proposal for "package" Keyword for ES20XX Imports

Tue Feb 21 20:59:44 UTC 2017

Fair enough. Is the idea that class declarations would be lazy-initialized
somehow then? It seems like the runtime behavior of class declarations
would make things difficult. What is responsible for knowing that the class
`A` needs to be initialized before `class B extends A {}`? What if the
declaration is using runtime behavior like `class B extends doThing(A) {}`?

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

> @Logan: Oh I see what you mean, I suppose I was thinking about it in a
> different way. I do know in ES6 the import keywords are always hoisted to
> the top, so it should be a given that the modules will be "resolved"
> already as a consequence of that. But there is no guarantee that all of the
> modules are linked successfully, namely in the edge cases of inheritance.
>
> Consider the following
>
> ```js
> // app.js
> import A from "./a.js";
> import B from "./b.js";
>
> var a = new A();
> var b = new B();
>
> // a.js
> import B from "./b.js";
>
> console.log("A's reference to B", B);
>
> export default class A {
>   constructor() {
>   }
> }
>
> // b.js
> import A from "./a.js";
>
> console.log("B's reference to A", A);
>
> export default class B extends A {
>   constructor() {
>     super();
>   }
> }
> ```
>
> In the latest Babel the above code fails to run on the first line of
> app.js (at the time it attempts to execute `_inherits(B, _A);`.). This is
> because "A" is undefined in module b.js due to the circular dependency. In
> this case Babel basically executed code in the incorrect order for this to
> be able to work. The package keyword avoids this by creating a hoist-like
> behavior for classes that are inherited, which is safe to do given the
> proposed limitations in the top-level scope
>
> I should note that circular dependencies like this are (hopefully) not too
> common, but one coming from another language might expect this to work
> based on how ES6 imports are described. I think the behavior of the package
> keyword could be much more transparent about what it's capable of.
>
>
>
> On Tue, Feb 21, 2017 at 1:56 PM, Logan Smyth <loganfsmyth at gmail.com>
> wrote:
>
>> 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 <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/3b7e81fa/attachment.html>