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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
