Idea for namespace management and importing internal modules

Topics: General, Language Specification
Jan 30, 2014 at 2:31 AM
I'd like to have some slightly slicker syntax for managing namespaces. Here's what I currently have to write:
module A {
  export var a1 = "a1";
  export var aN = "aN";
}

module B {
  import a1 = A.a1;
  import aN = A.aN;
  var i = "i: " + a1;
  export var y = i + " :y: " + aN;
}

module B {
  import a1 = A.a1;
  import aN = A.aN;
  export var z = "z: " + y + aN;
}
Here's what I think I should have to write:
module A {
  export var a1 = "a1";
  export var aN = "aN";
}

module B {
  import A.*;
  var i = "i: " + a1;
  export var y = i + " :y: " + aN;
}

module B {
  import A.*;
  export var z = "z: " + y + aN;
}
Being able to move names into the current scope on mass (or, equivalently, compile to longer names) is important sometimes. This would also provide a solution to some of the other discussion on modules and namespaces I've seen. What do you think?
Jan 30, 2014 at 6:58 PM
Well if you look at the current harmony modules proposal there are a few enhancements compared to the current TS import/exports ( http://wiki.ecmascript.org/doku.php?id=harmony:modules#quick_examples ).

For example importing serveral names from one module and binding them to local variables:
import { encrypt, decrypt } from "crypto"; // binding a module's exports to variables
Jan 30, 2014 at 7:29 PM
Cool ideas. But the current harmony modules proposal does not include importing a namespace into a current module to avoid typing a prefix; at least according to the proposed syntax. Having said that, some of the discussion/rationale seems to suggest that "import *" is allowed:

http://wiki.ecmascript.org/doku.php?id=harmony:modules_rationale#scoping_semantics

So would be really great to have typescript support this too :-)
Mar 4, 2014 at 5:55 PM
Two thoughts:

A name to alias the import.
import A.B as AB; // everything in A.B is now available under AB

Or a wildcard import:
import {*} from "crypto"; // everything, not just encrypt and decrypt, are locally bound now.
Developer
Mar 4, 2014 at 8:08 PM
As has been alluded to, we have been intentionally conservative with some of the module features/syntax while the ES6 proposals were/are in flux. We definitely don't want to end up painting ourselves into a corner and not being able to support all the ES6 features because of some TypeScript specific conveniences that could've been added later. There's certainly plenty of room for improvement in the module story though and we'll be looking at cases like this along with others while trying to sync up with what ES6 supports.

As far as prefixes go, the export= syntax does help in some cases with that.
Jun 22, 2014 at 4:41 AM
Any update? :)