Module Comments

Andreas Rossberg rossberg at google.com
Fri Dec 7 01:55:08 PST 2012


On 6 December 2012 17:54, Kevin Smith <khs4473 at gmail.com> wrote:
>
>> Note, however, that you still assume some hack in the semantics with
>> the "if it exists" part. To avoid that, you need to divorce the import
>> syntax from the naming-an-external-module syntax -- which I'd actually
>> prefer anyway, and which was the case in the previous version of the
>> proposal.
>
> Could we eliminate the hack on the export side instead?
>
> Every module instance has a $DEFAULT export binding.  Normally, it is set to
> the module instance itself.  `export = ?` overrides the value of that
> binding.  `import x from "y"` binds $DEFAULT in "y" to x.  Maybe?

Well, in my book, that doesn't count as eliminating the hack, but
rather broadening it to all sides. Moreover, it still prevents you
from getting a handle on the module itself. In fact, I believe this is
pretty much equivalent to what's currently in the proposal.

For the record, what I have in mind is similar to your previous
suggestion, namely treating

  export = exp

as special syntax for the pseudo declaration

  export let export = exp

(where the second 'export' is meant to act as an identifier/property
name). And e.g.

  import x from "url"

as

  import {export: x} from "url"

For module naming, we'd need to have a different syntax. In earlier
versions of the proposal that was

  module x at "url"

which would still be usable even for modules using special exports.
Note also that using the special export would not be mutually
exclusive with having other exports, so in that sense, it is like your
$DEFAULT, but far less magic.

/Andreas


More information about the es-discuss mailing list