Suggestion: Anonymous/Unnamed Modules

[omidkrad]

Suggestion moved over from codeplex.

I would like to suggest the following: Why not have anonymous/unnamed modules? The following code snippet totally makes sense for me to compile:

module {
  class Simple {

    constructor(public name: string) {}

    greet(who: string) {
      return "Greetings "+ who +", I'm "+ this.name +"!";
    }

    static main() {
      var s = new Simple('Flynn');
      console.log(s.greet("Program"));  
    }

  }

  Simple.main()
}

The generated code should be wrapped in a closure function and not cluttering the global scope.

(function () {

 // ...

})();

Also it would be nice to have a compiler option to put everything compiled in an anonymous module so that the global namespace is not cluttered.

The above snippet is with little modification from: https://gist.github.com/3916195

Thanks!

[RyanCavanaugh]

Stating the obvious stuff to round this out:

• export inside this module is disallowed
• Anonymous modules generate nothing in .d.ts files
• Symbol binding is unaffected compared to an unspeakable-named module
• No merging takes place across anonymous modules

[RyanCavanaugh]

Ready for discussion on this one.

[johnnyreilly]

I like this idea. I find it frustrating that I can't nest classes in IIFEs and always have to declare a named module. 👍 for this.

As an aside, will es6 classes be declarable inside an IIFE? I presume so? It would be nice if TypeScript classes could be nested in an IIFE so when migrating es6 code to TypeScript you weren't forced to migrate to modules if you didn't want to - same restrictions as specified by @RyanCavanaugh obviously.

[omidkrad]

I sometimes find IIFEs to be a little too verbose, especially when they are nested. Does it make sense to have the followings to be interchangeably equivalent?

(function() { /*code*/ })()

(() => { /*code*/ })()

module { /*code*/ }

[danquirk]

@johnnyreilly yes ES6 supports class expressions so you'd be able to nest class definitions in all sorts of places

[johnnyreilly]

@omidkrad - yes that's exactly what I was hoping for. Much cleaner to the eye. Though I'd quite like classes to be allowed in IIFE's anyway since it's going to be valid JavaScript when ES 6 finally ships. (And since one of TypeScript's original design goals was to be a superset of JavaScript I would guess that it makes sense for this to come along for the ride.)

@danquirk - thanks for clarifying.

[msridhar]

+1 on this issue. Is there a workaround in the meantime? I.e., is there a way for me to create classes, enums, etc. visible only within a single source file, without having to declare a module name that ends up as a (browser) global variable? I guess I could delete that variable afterward, but I was hoping for something cleaner.

[RyanCavanaugh]

Discussed in design meeting and declined. Relevant points:

• We'll have local types (class declarations at block scope) in the future, at which point an IIFE is usable instead
• You can just use a nonsense name as the module name with little risk of meaningfully altering the global scope
• Not enough value relative to the complexity it adds

[johnnyreilly]

Hi @RyanCavanaugh,

Understand that this is declined. Could you clarify what "local types (class declarations at block scope)" means with an example please? I may be being a bit dense but I'm not sure what this is.

I take it from what you've said that that classes will become usable inside IIFEs at that point?