Hi Alex,
No matter what language, I think Generics are usually a compile time thing. I bet the MS guys won't be able to implement Runtime generics on top of JavaScript :) I think the Parser part would be the part I can help with ... I like Antlr (even the old versions) I should manage to adjust the parser grammar to produce some additional AST nodes. It was more the other part that I was worried about. Seems together this would be a huge thing. Espsecially because I noticed people drop all their predudices against Flex as soon as you state: "We're more or less the same as TypeScript, but we have loads of well established libraries to use" ... currently the thing I always here is "but Typescript has Generics ... and I like Generics" I would so desperately like to get rid of that reply ;-) Chris ________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Dienstag, 27. September 2016 22:25:46 An: dev@flex.apache.org Betreff: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import) It should be possible to add compile-time language features like Generics. There might be issues around runtime type conversions though. I'd be willing to help with the AST->output side. For me the part that wouldn't be any fun would be in changing the parser to build out the AST. If someone can make the changes to create a tree of new Node subclasses, I will try to get the right JS and SWF output to happen. The SWF output would probably be the hardest. -Alex On 9/27/16, 8:10 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >In general I have no objections and something like this could sometimes >be really handy. But I with this we could be writing code that is called >ActionScript3 but without it actually being ActionScript3. > > >While preparing my talk to Solutions.Hamburg a few weeks ago, I had a >detailed look at Typescript and noticed with a little jealousy some >language features I would really like to have: > > >- Generics > >- Arrow Functions > >- Enum types > > >I guess we definitely shouldn't support all features, as I think a lot of >them are simply crap, but if we were supporting these features we could >eventually get more Typescript fans on board (Generics being the most >important one from my point of view) > > >I was thinking about proposing to define an ActionScript4 with file >ending as4 so eventually this would be the better approach. Eventually it >would be a good idea to start collecting features as we wouldn't want to >do an AS5, AS6, ... AS2000 every now and then. > > >Chris > >________________________________ >Von: Josh Tynjala <joshtynj...@gmail.com> >Gesendet: Dienstag, 27. September 2016 16:59:33 >An: dev@flex.apache.org >Betreff: [Falcon] Proposal for new ActionScript language feature: >Optionally rename an import > >I would like to propose a new feature for the ActionScript language in the >Apache Flex "Falcon" compiler. It would be nice if developers could >(optionally) rename an import. > >Background >========== > >Normally when you import a class, you can reference the name of the class, >without the package (unless there is another class with the same name): > >// begin example > >import com.example.ImportedClass; > >var example:ImportedClass; > >//end example > >I would like to make it possible to optionally rename the shortened >version, like this: > >// begin example > >import NewName = com.example.ImportedClass; > >var test:NewName; > >//end example > >This would make it possible to resolve ambiguities without using the >fully-qualified class name. Consider the following situation that commonly >comes up when developing Starling apps where the fully-qualified name is >required for different types of events: > >// begin example > >import flash.events.Event; >import starling.events.Event; > >var one:flash.events.Event; >var two:starling.events.Event; > >// end example > >If we could rename imports, our code wouldn't require cumbersome >fully-qualified names. > >Consider the following example, references to FlashEvent will resolve to >flash.events.Event and StarlingEvent will resolve to >starling.events.Event: > >// begin example > >import FlashEvent = flash.events.Event; >import StarlingEvent = starling.events.Event; > >var one:FlashEvent; >var two:StarlingEvent; > >// end example > >In the next example, references to FlashEvent will resolve to >flash.events.Event, similar to the previous example. References to Event >can resolve to starling.events.Event without ambiguity because >flash.events.Event has been given a different name. > >// begin example > >import FlashEvent = flash.events.Event; >import starling.events.Event; > >var one:FlashEvent; >var two:Event; > >// end example > >This would also be useful for transpile-to-JS workflow where the top-level >package is littered with a ton of HTML classes that may conflict with >names >user-defined classes. For instance, there's a top-level Event class. There >is no way to specify a different fully-qualified name for things in the >top-level package, so it's hard to resolve ambiguity when using these >classes. We have a bit of a workaround in Falcon by supporting a fake >"window." package, but that's not ideal. Especially if you consider >Node.js, which doesn't actually have a global window object. > >Risks and Challenges >=================== > >* Renaming imports is a completely optional feature. Anyone can continue >to >code in ActionScript without ever using renamed imports. >* Existing code won't be broken by this new feature. Regular imports that >don't do any renaming will continue to work the same as they always have. >* Runtimes like Adobe Flash Player will not need to be modified to support >renaming imports. Imports are completely resolved at compile-time. >* A SWC compiled from code with renamed imports will work with compilers >that don't support renaming imports. Again, a SWC contains compiled code, >so imports were already resolved. >* I have implemented this feature already, in a local branch of >flex-falcon >on my machine. The code already exists, and it works today. > >The one tricky thing is that most IDEs probably won't play well with code >that uses renamed imports. My NextGenAS extension for VSCode should have >no >problem because it loads the Falcon compiler from the Apache FlexJS SDK >for >its code intelligence features. If Falcon supports it, so will the >extension. Adobe Flash Builder uses ASC 2.0 in a similar way, as I >understand it. With that in mind, Flash Builder won't understand code with >renamed imports unless Adobe modifies ASC 2.0 to add the same feature. I >think third-party IDEs (like IntelliJ IDEA and FDT) have their own code >models (rather than talking to the compiler), so they'd need to make their >own changes to support this feature too. > >I would like to contact the Flash runtimes team at Adobe and ask if they'd >be willing to implement this feature in ASC 2.0 too. It's a small change, >but useful for developer productivity, so it should be well received by >the >community. Additionally, since it will affect the compiler and not the >runtime, it will be significantly less risky for Adobe than other new >language features might be. Finally, considering that the Falcon and ASC >2.0 codebases are probably still extremely similar, I wouldn't be >surprised >if the changes were exactly the same. To go back to the previous point >about IDEs, I'm pretty sure that if ASC 2.0 supports this feature, Flash >Builder will get it for free when someone upgrades the AIR SDK used by the >FB plugin. There may still be some quirks (I'm curious to see if >organizing >imports breaks or not), but I think ActionScript developers are used to a >few occasional quirks these days. > >Comments welcome. > >- Josh
