On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith <zenparsing at gmail.com> wrote:

>
>>
>> Because it doesn't allow for the Assignment Expression form
>> (specifically, function expressions) that developers expect to be able to
>> write:
>>
>>   export default function() {}
>>
>
> The alternative here is:
>
>     function MyThing() {}
>     export { MyThing as default };
>
> Which is more clear, more readable,
>

I think it's fair to say that these are subjective claims.


> and barely less ergonomic.  If you *really* want the AssignmentExpression
> form, you've got to put the equals in there.
>

I don't understand this claim, any legal AssignmentExpression form is
allowed.


> I've said this before, but without the equals it looks too much like a
> declaration:
>
>     export default class C {}
>     var c = new C(); // No C defined, WTF?
>

Why is this surprising? Named function expressions don't create a lexical
binding for their name and therefore cannot be called by that name from
outside of the function body:

  var f = function a() {};

  a(); // nope.

The same thing applies to class expressions, which is what is written in
your example--"class C {}" is effectively the same as the expression
_between_ "=" and ";" of the following:

  var D = class C {};

And no one would expect to be able to this:

  var c = new C();


But if you used the `export Declaration` form, it will work (as it does
today, without `export` of course):

  export class C {}
  var c = new C();

  export function F() {}
  var f = new F();


> Node users don't elide the equals sign, do they?
>

>     module.exports = whateva;
>
> So why are we?
>

To make a single form that works across platforms (ie. an amd module
doesn't "just work" in node and vice versa). I don't think this is strong
enough to be considered a valid counter-point, I recommend not pursuing it.
`export default function() {}` will work the same way on all platforms.


>
> Equals aside, let's look at the cost/benefit ratio here:
>
> - Benefit: a little less typing (at most one savings per module)
> - Cost: more confusion and StackOverflow questions about default export
> syntax.
>

If a developer knows how named function expression bindings work today,
this won't be a big surprise.


Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140314/89ed66f6/attachment.html>

On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> The alternative here is:
>
>     function MyThing() {}
>     export { MyThing as default };
>
> Which is more clear, more readable,

I think it's fair to say that these are subjective claims.


> and barely less ergonomic.  If you *really* want the AssignmentExpression
> form, you've got to put the equals in there.

I don't understand this claim, any legal AssignmentExpression form is
allowed.


> I've said this before, but without the equals it looks too much like a
> declaration:
>
>     export default class C {}
>     var c = new C(); // No C defined, WTF?

Why is this surprising? Named function expressions don't create a lexical
binding for their name and therefore cannot be called by that name from
outside of the function body:

    var f = function a() {};
    a(); // nope.

The same thing applies to class expressions, which is what is written in
your example--"class C {}" is effectively the same as the expression
_between_ "=" and ";" of the following:

    var D = class C {};

And no one would expect to be able to this:

    var c = new C();

But if you used the `export Declaration` form, it will work (as it does
today, without `export` of course):

    export class C {}
    var c = new C();

    export function F() {}
    var f = new F();


> Node users don't elide the equals sign, do they?
>
>     module.exports = whateva;
>
> So why are we?

To make a single form that works across platforms (ie. an amd module
doesn't "just work" in node and vice versa). I don't think this is strong
enough to be considered a valid counter-point, I recommend not pursuing it.
`export default function() {}` will work the same way on all platforms.


> Equals aside, let's look at the cost/benefit ratio here:
>
> - Benefit: a little less typing (at most one savings per module)
> - Cost: more confusion and StackOverflow questions about default export syntax.

If a developer knows how named function expression bindings work today,
this won't be a big surprise.