It doesn’t seem like an impossible problem since other platforms solve this fine without compromising on static analyzability (e.g. Haskell I imagine). But I must admit I’m completely unfamiliar what particular sticking points in the JavaScript platform particularly rule out the possibility of this feature.
Jason > On Feb 19, 2015, at 8:12 PM, caridy <car...@gmail.com> wrote: > > Jason, the most important feature of ES modules is that they are statically > verifiable. Something like `import * from “./foo”` goes against that > principle because you cannot know ahead of time what are those specifiers. > Essentially, you will have to type those specifiers no matter what :), no > sugar will save you from that. > > /caridy > >> On Feb 19, 2015, at 8:02 PM, Jason Kuhrt <jasonku...@me.com >> <mailto:jasonku...@me.com>> wrote: >> >> Hi Caridy, >> >> I think you misunderstood my comment about >> >> import * from ‘./foo’ >> >> I am aware of >> >> import * as foo from ‘./foo’ >> >> and that is fine. My former example is the desire to have `foo`’s exports >> injected as-is into the module’s scope (bar vs foo.bar, etc.). There are >> times where this is desirable, wherein enumerating { bar1, bar2, bar3, >> barN... } is just a waste of time and maintenance headache. >> >> As for refactoring hazards I can appreciate that JavaScript has a lot more >> to protect against than strongly typed languages. Refactoring in JavaScript >> is generally unsafe for any number of reasons. >> >> Jason >> >> >> >>> On Feb 19, 2015, at 7:55 PM, caridy <car...@gmail.com >>> <mailto:car...@gmail.com>> wrote: >>> >>> inline >>> >>>> On Feb 19, 2015, at 7:50 PM, Jason Kuhrt <jasonku...@me.com >>>> <mailto:jasonku...@me.com>> wrote: >>>> >>>> Hey Matthew, >>>> >>>> This is another pattern I could take yup. >>>> >>>> Kevin pointed that if I suck it up and move all my modules toward >>>> named-exports then my problems go away too. The reason I am using default >>>> internally was that I had modules depending on others which are all >>>> uniformly single-function modules (react components to be specific). So it >>>> felt confusing to have this syntax internally: >>>> >>>> import { foo } from ‘../foo’ >>>> >>>> When what I’m really trying to express is: >>>> >>>> import foo from ‘../foo’ >>>> >>>> But ultimately if I am willing to accept that internally I use the former >>>> syntax then my re-export expressions are fine: >>>> >>>> export * from ‘./foo’ >>> >>> In my mind, this is good for proxy modules, shims, and other edge cases, >>> but keep in mind that excessive usage of this (e.g.: multiple export *… in >>> the same module) can become a refactor hazard. >>> >>>> These are small details but added up they matter. Generally I’m happy with >>>> modules though. The only other gripe I have is not being able to import >>>> each export naked into a namespace like this: >>>> >>>> import * from ‘./foo’ >>> >>> that’s exactly what `import * as foo from “./foo”` does it :) >>> >>> /caridy >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
