@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
