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
