From: Patrick Mueller
> On Wed, Oct 17, 2012 at 5:04 PM, Russell Leggett <[email protected]>
> wrote:
>> module "a.js" {
>> import b from "b.js";
>> console.log("a");
>> export let a = "a";
>> }
>> module "b.js" {
>> console.log("b");
>> export let b = "b";
>> }
>> //main.js
>> import a from "a.js";
>> console.log("main");
>> The idea here, is to allow a new bit of syntax where the module identifier
>> is a string literal. If that is the case, it assumes the module is loaded in
>> place of a file, where the url for the file is the value of the string
>> literal. Just to be clear, though, it doesn't actually execute the module at
>> all - it just caches it in the loader.
> Ya, I kinda like that. Basically let's me mark an "internal" module as an
> "external one" - I even get to assign a "file name", which maybe a debugger
> can make sense of. Win!
Of note, TypeScript currently uses a similar syntax to solve a variant of this
problem. To describe the surface area of an API like the core node.js modules,
we wanted a way for a single file to describe all of the modules that are made
available within a bare node.js installation. This includes the ability to
declare:
declare module "http" {
export function get(options, callback);
//...
}
Indicating that a module named "http" exists and has the listed members.
TypeScript does not yet support a syntax for actually implementing a module
using this form, but Russell's syntax is almost exactly what would make sense
as a logical extension of the declaration syntax.
The key difference between internal module definitions and Russell's inline
external module definition syntax is that the later creates no lexical binding
at the site of its declaration, and just puts an entry in the loader table.
This feels to me like a clean way to support the concatenation scenarios
discussed in this thread, while still supporting the IIFE module patterns that
motivate internal modules.
Luke
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
