Re: Re-export default?

2015-02-19 Thread Jason Kuhrt
“foo”;` this is just sugar for: `export {default} from “foo”;` which is perfectly supported in ES6, including the ability to rename it: `export {default as something} from “foo”;` /caridy On Feb 18, 2015, at 9:08 PM, Jason Kuhrt jasonku...@me.com mailto:jasonku

Re-export default?

2015-02-18 Thread Jason Kuhrt
I was prompted to bring this issue to es-discuss. https://github.com/babel/babel/issues/826 https://github.com/babel/babel/issues/826 It is my confusion about why this syntax does not work: export foo from ‘./foo' More details are in the issue but the gist is that sometimes it is actually

Re: Re-export default?

2015-02-19 Thread Jason Kuhrt
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

Re: Re-export default?

2015-02-19 Thread Jason Kuhrt
number of reasons. Jason On Feb 19, 2015, at 7:55 PM, caridy car...@gmail.com wrote: inline On Feb 19, 2015, at 7:50 PM, Jason Kuhrt 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

Re: Re-export default?

2015-02-19 Thread Jason Kuhrt
not simply import a from a; import b from b; export { a, b }; On Feb 19, 2015 8:18 AM, Jason Kuhrt jasonku...@me.com mailto:jasonku...@me.com wrote: I hear the verdict but not any substantial rationale; why is it “confusing”?’ @caridy regarding your examples for JS2016 wouldn’t

Re: Re-export default?

2015-02-19 Thread Jason Kuhrt
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

Re: Re: Re-export default?

2015-04-04 Thread Jason Kuhrt
This proposal would solve my issues: https://github.com/leebyron/ecmascript-more-export-from https://github.com/leebyron/ecmascript-more-export-from And alas it seems I was correct that this is not an impossible problem to solve at all.___ es-discuss

Re: Re: Named `this` and `this` destructuring

2015-06-17 Thread Jason Kuhrt
Exactly what Allen said. Adding syntax to work around a bad feature is an awful idea. We should be trying to reduce and remove usage of `this` by reducing resistance to other ways of programming in JavaScript. Minimal API Surface areas apply to languages, not just libraries.

Re: Will FP ever have a great Stack Trace story in JS?

2015-09-16 Thread Jason Kuhrt
> > > ``` > > let compose = (b, a) => (...as) => b(a(...as)) > > ``` > > > As that's clearly not the issue in your stack trace. > > Also, if you want these stack traces to be more meaningful, you should be > talking to the JavaScript engine implementor

Re: Will FP ever have a great Stack Trace story in JS?

2015-09-16 Thread Jason Kuhrt
> named “x”, etc). > > It does not apply to things like `compose(thingA, thingB)`, which is not an > anonymous function definition.These function names aren’t set at runtime, > it’s a parse-time operation, and depends on the productions that are parsed. > >> On Sep 16, 20

Re: Will FP ever have a great Stack Trace story in JS?

2015-09-16 Thread Jason Kuhrt
tions that might need debugging. > > I also don't see what this has to do with your FP example of: > > > > ``` > > let compose = (b, a) => (...as) => b(a(...as)) > > ``` > > > As that's clearly not the issue in your stack trace. > > Also, if you want

Will FP ever have a great Stack Trace story in JS?

2015-09-16 Thread Jason Kuhrt
For example, today, a stone from the bedrock of FP: > ``` > let compose = (b, a) => (...as) => b(a(...as)) > ``` will cause a JS Stack Trace to go from something useful (space around useful line) like: > ``` > Error: Invariant Violation: createClass(...): Class specification must > implement