You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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.)
+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.
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?
Activity
RyanCavanaugh commentedon Jul 23, 2014
Stating the obvious stuff to round this out:
exportinside this module is disallowedRyanCavanaugh commentedon Jul 28, 2014
Ready for discussion on this one.
johnnyreilly commentedon 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.
omidkrad commentedon Jul 29, 2014
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?
danquirk commentedon Jul 29, 2014
John Reilly (@johnnyreilly) yes ES6 supports class expressions so you'd be able to nest class definitions in all sorts of places
johnnyreilly commentedon 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.
msridhar commentedon 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
deletethat variable afterward, but I was hoping for something cleaner.RyanCavanaugh commentedon Sep 19, 2014
Discussed in design meeting and declined. Relevant points:
johnnyreilly commentedon 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?
RyanCavanaugh commentedon Sep 29, 2014
Certainly; the idea is that we will in the future allow code like this:
johnnyreilly commentedon Sep 30, 2014
Fantastic! Thanks Ryan Cavanaugh (@RyanCavanaugh)
msridhar commentedon Sep 30, 2014
Yes, thanks to Ryan Cavanaugh (@RyanCavanaugh) and the TypeScript team for all the great work!
omidkrad commentedon Oct 8, 2014
Awesome!
NN--- commentedon Jan 15, 2015
Just today I needed anonymous module and ended with UniqueName.
svicalifornia commentedon Jan 25, 2015
Ryan Cavanaugh (@RyanCavanaugh) What complexity does this add, really?
danquirk commentedon Jan 26, 2015
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.
johnnyreilly commentedon Jan 26, 2015
Fascinating post Dan Quirk (@danquirk)! - Thanks for sharing.
rcollette commentedon May 19, 2015
Ryan Cavanaugh (@RyanCavanaugh) - Have local types been implemented in 1.5-beta? I'm trying
And still getting `TS1129 statement expected. class must be in a file or module context.
danquirk commentedon May 19, 2015
Richard Collette (@rcollette) local types are not implemented at present. They're scheduled for 1.6: https://github.com/Microsoft/TypeScript/wiki/Roadmap
sophiajt commentedon Jun 11, 2015
Just to follow up - #3266, so this is now supported.
johnnyreilly commentedon Jun 11, 2015
Awesome!
omidkrad commentedon Jun 12, 2015
Fantastic!