Default exports, without explicit syntactic support

[John Barton]

On Thu, Jun 26, 2014 at 7:39 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

>     // my-class.js
>     export class MyClass {
>         constructor() { ... }
>         method() { ... }
>     }
>
>     // use-class.js
>     import { MyClass } from "my-class.js";
>
>
> You do have redundancy in `my-class.js` and, as Marius pointed out, the
> importer has to know both the name of the module and the name of the entity
> inside the module. Not that big of a deal.
>

But these examples are misleading. "my-class.js" is not the name of the
module. Its is a module identifier, and probably incorrect since the
identifier is both absolute and ending in .js.

A more realistic example is

import {MyClass} from "./pretentious/kernel/core/util/my-class";

In the big picture the time to type a few characters in regular pattern is
completely overwhelmed by the time it takes to figure out what MyClass does
and where it lives.



> Again, standardizing on `_` for default exports helps,
>

I guess you meant "developers may choose to adopt short export
identifiers"; I don't suppose you are proposing to standardize _.


> but then importing is more verbose:
>
>     // my-class.js
>     export class _ {
>
>         constructor() { ... }
>         method() { ... }
>     }
>
>     // use-class.js
>     import { _ as MyClass } from "my-class.js";
>
> --
> Dr. Axel Rauschmayer
> axel at rauschma.de
> rauschma.de
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140626/f2ee9be5/attachment-0001.html>