Skip to content

Suggestion: Anonymous/Unnamed Modules #206

Closed
Closed
Suggestion: Anonymous/Unnamed Modules#206
Labels
DeclinedThe issue was declined as something which matches the TypeScript visionSuggestionAn idea for TypeScript

Description

@omidkrad
Omid K. Rad (omidkrad)
opened on Jul 23, 2014

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://github.com/proxy/gist.github.com/3916195

Thanks!

Activity

  1. Ryan Cavanaugh (RyanCavanaugh)
    added
    Suggestion
    on Jul 23, 2014

  2. RyanCavanaugh commented on Jul 23, 2014

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Jul 23, 2014
    Member

    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
  3. Ryan Cavanaugh (RyanCavanaugh)
    added
    In Discussion
    on Jul 28, 2014

  4. RyanCavanaugh commented on Jul 28, 2014

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Jul 28, 2014
    Member

    Ready for discussion on this one.

  5. johnnyreilly commented on Jul 29, 2014

    @johnnyreilly
    John Reilly (johnnyreilly)
    on Jul 29, 2014

    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 Ryan Cavanaugh (@RyanCavanaugh) obviously.

  6. omidkrad commented on Jul 29, 2014

    @omidkrad
    Omid K. Rad (omidkrad)
    on Jul 29, 2014
    Author

    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*/ }

  7. danquirk commented on Jul 29, 2014

    @danquirk
    Dan Quirk (danquirk)
    on Jul 29, 2014
    Member

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

  8. johnnyreilly commented on Jul 30, 2014

    @johnnyreilly
    John Reilly (johnnyreilly)
    on Jul 30, 2014

    Omid K. Rad (@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.)

    Dan Quirk (@danquirk) - thanks for clarifying.

  9. msridhar commented on Sep 18, 2014

    @msridhar
    Manu Sridharan (msridhar)
    on Sep 18, 2014

    +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.

  10. Ryan Cavanaugh (RyanCavanaugh)
    added
    DeclinedThe issue was declined as something which matches the TypeScript vision
    and removed
    In DiscussionNot yet reached consensus
    on Sep 19, 2014

  11. RyanCavanaugh commented on Sep 19, 2014

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Sep 19, 2014
    Member

    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
  12. Ryan Cavanaugh (RyanCavanaugh)
    closed this as completedon Sep 19, 2014

  13. johnnyreilly commented on Sep 29, 2014

    @johnnyreilly
    John Reilly (johnnyreilly)
    on Sep 29, 2014

    Hi Ryan Cavanaugh (@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?

  14. RyanCavanaugh commented on Sep 29, 2014

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Sep 29, 2014
    Member

    Certainly; the idea is that we will in the future allow code like this:

    function f() { // or any function expression or any method body
    interface b { /* ... */ }
    class c { /* ... */ }
    // etc
}

  15. johnnyreilly commented on Sep 30, 2014

    @johnnyreilly
    John Reilly (johnnyreilly)
    on Sep 30, 2014

    Fantastic! Thanks Ryan Cavanaugh (@RyanCavanaugh)

  16. msridhar commented on Sep 30, 2014

    @msridhar
    Manu Sridharan (msridhar)
    on Sep 30, 2014

    Yes, thanks to Ryan Cavanaugh (@RyanCavanaugh) and the TypeScript team for all the great work!

  17. omidkrad commented on Oct 8, 2014

    @omidkrad
    Omid K. Rad (omidkrad)
    on Oct 8, 2014
    Author

    Awesome!

  18. NN--- commented on Jan 15, 2015

    @NN---
    NN (NN---)
    on Jan 15, 2015

    Just today I needed anonymous module and ended with UniqueName.

  19. svicalifornia commented on Jan 25, 2015

    @svicalifornia
    Shawn Van Ittersum (svicalifornia)
    on Jan 25, 2015

    Ryan Cavanaugh (@RyanCavanaugh) What complexity does this add, really?

  20. danquirk commented on Jan 26, 2015

    @danquirk
    Dan Quirk (danquirk)
    on Jan 26, 2015
    Member

    This seems relevant to answer that: http://blogs.msdn.com/b/ericgu/archive/2004/01/12/57985.aspx

    The issue is that it doesn't add much value on its own and it adds non-zero complexity that can't ever be removed.

  21. johnnyreilly commented on Jan 26, 2015

    @johnnyreilly
    John Reilly (johnnyreilly)
    on Jan 26, 2015

    Fascinating post Dan Quirk (@danquirk)! - Thanks for sharing.

  22. rcollette commented on May 19, 2015

    @rcollette
    Richard Collette (rcollette)
    on May 19, 2015

    Ryan Cavanaugh (@RyanCavanaugh) - Have local types been implemented in 1.5-beta? I'm trying

    (function(){
  class x{

  }
})()

    And still getting `TS1129 statement expected. class must be in a file or module context.

  23. danquirk commented on May 19, 2015

    @danquirk
    Dan Quirk (danquirk)
    on May 19, 2015
    Member

    Richard Collette (@rcollette) local types are not implemented at present. They're scheduled for 1.6: https://github.com/Microsoft/TypeScript/wiki/Roadmap

  24. sophiajt commented on Jun 11, 2015

    @sophiajt
    Sophia J. Turner (sophiajt)
    on Jun 11, 2015
    Contributor

    Just to follow up - #3266, so this is now supported.

  25. johnnyreilly commented on Jun 11, 2015

    @johnnyreilly
    John Reilly (johnnyreilly)
    on Jun 11, 2015

    Awesome!

  26. omidkrad commented on Jun 12, 2015

    @omidkrad
    Omid K. Rad (omidkrad)
    on Jun 12, 2015
    Author

    Fantastic!

  27. microsoft
    locked and limited conversation to collaborators on Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DeclinedThe issue was declined as something which matches the TypeScript visionSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions