d at domenic.me (2015-03-03T21:09:04.285Z)
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.
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 <caridy at 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 <jasonkuhrt at me.com <mailto:jasonkuhrt at 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 <caridy at gmail.com <mailto:caridy at gmail.com>> wrote: >>> >>> inline >>> >>>> On Feb 19, 2015, at 7:50 PM, Jason Kuhrt <jasonkuhrt at me.com <mailto:jasonkuhrt at 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150219/d58c20f3/attachment-0001.html>