flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)
Date Tue, 27 Sep 2016 20:40:26 GMT
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 <aharui@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.dutz@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 <joshtynjala@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message