As Flex was evolving through the years and things like Swiz born, I always want all this things implemented. This haxe framework has more of the things you would want: http://hexmachina.org/ But AFAIK, it lacks of something critical: MXML (for this reason haxe is still no option for many of us, since the main focus is gaming and not application development)
Flex has, for me, three key points that make it a pleasure to work with: MXML, RPC (AMF mainly, but not alone) and Application System Manager (managers, and all the things that make it work seamlessly). FlexJS, has MXML, but still lacks RPC-AMF and App Sys Manager (AFAIK) The things I would love to see in the future, and that will maintain the difference with plain javascript frameworks and technologies will be Generics, Anotations, Injection, IoC, and all modern facilities that are already in server side but not in web front ends. Btw, I think the import feature proposed by Josh will be cool 2016-09-27 17:10 GMT+02:00 Christofer Dutz <christofer.d...@c-ware.de>: > 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 > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
