Written Proposal for "package" Keyword for ES20XX Imports

Isiah Meadows isiahmeadows at gmail.com
Wed Feb 22 17:50:14 UTC 2017


I'll point out that Babel doesn't follow spec perfectly because it can't
transpile the bindings correctly in the case of synchronously executed code
with circular dependencies. That's a CommonJS limitation that Babel can't
work around any more than it already does.

On Tue, Feb 21, 2017, 17:54 Greg McLeod <cleod9 at gmail.com> wrote:

> @Logan
>
> Yes that's correct more or less. This is demonstrated with the
> `module.injects` concept showcased in the Gist. Any inheritance that occurs
> at the top of level of a module can be statically detected by parsing the
> AST for `extends` within that scope. Keywords found after an `extends`
> could be given execution priority so that they are imported inline
> immediately. All other exported class declarations that don't have an
> `extends` can be deferred via the injection mechanism shown in the example
> code.
>
> In the case of dynamic extension with `extends doThing(A)`, both `doThing`
> and `A` would need to treated with priority. Though I imagine for a first
> iteration of something like this there could be a restriction on that type
> of syntax while those details are fleshed out to keep things maximally
> minimal.
>
> On Tue, Feb 21, 2017 at 3:59 PM, Logan Smyth <loganfsmyth at gmail.com>
> wrote:
>
> 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
>
>
>
>
>
> _______________________________________________
> 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/20170222/6040bbc1/attachment.html>


More information about the es-discuss mailing list