Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

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" <ch...@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 <jo...@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

AW: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Christofer Dutz <ch...@c-ware.de>]

That was initially the reasoning for me suggesting an as4 instead of extending as3.

An alternative would be to control this with a compiler switch ... sort of like the quirks mode in the browsers (does that still exist?). I'm just thinking of all of these "Fun with JavaScript" in which you can fill hours with unexpectable JavaScript results.


Chris

________________________________
Von: Alex Harui <ah...@adobe.com>
Gesendet: Mittwoch, 28. September 2016 19:29:22
An: dev@flex.apache.org
Betreff: Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)



On 9/28/16, 8:37 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>For core classes like Number, Array, Boolean, etc. what looks like a cast
>is actually a function call. There's a global function named Array, and
>calling that takes precedence over casting.
>
>Personally, I think we should avoid breaking changes like this.

Me too, especially since, on the SWF side, the runtime is handling this.
As annoying as it is, we have to maintain backward compatibility.

-Alex

Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

On 9/28/16, 8:37 AM, "Josh Tynjala" <jo...@gmail.com> wrote:

>For core classes like Number, Array, Boolean, etc. what looks like a cast
>is actually a function call. There's a global function named Array, and
>calling that takes precedence over casting.
>
>Personally, I think we should avoid breaking changes like this.

Me too, especially since, on the SWF side, the runtime is handling this.
As annoying as it is, we have to maintain backward compatibility.

-Alex

Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Josh Tynjala <jo...@gmail.com>]

For core classes like Number, Array, Boolean, etc. what looks like a cast
is actually a function call. There's a global function named Array, and
calling that takes precedence over casting.

Personally, I think we should avoid breaking changes like this.

- Josh

On Wed, Sep 28, 2016 at 4:58 AM, Christofer Dutz <ch...@c-ware.de>
wrote:

> Would also be a great opportunity to eventually cleanup some really
> anoying quirks in the Language specification ... stuff like if you try to
> cast to Array, you get a new one containing the input as single element ...
>
>
> var test:* = ["lalala", "dumdidum"];
>
> var arr:Array = Array(test);
>
> trace(arr);
>
>
> returns something like this:
>
> [["lalala", "dumdidum"]]
>
>
> if I do
>
> var test:* = ["lalala", "dumdidum"];
>
> var arr:Array = test as Array;
>
> trace(arr);
>
>
> I get:
>
> ["lalala", "dumdidum"]
>
>
> I think there were one or two other exceptions, that really really anoy me
> and probably others too.
>
>
> Chris
>
> ________________________________
> Von: Josh Tynjala <jo...@gmail.com>
> Gesendet: Mittwoch, 28. September 2016 02:50:12
> An: dev@flex.apache.org
> Betreff: Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript
> language feature: Optionally rename an import)
>
> I agree with your point about numerous changes. I think that's something
> that I didn't fully catch when reading your message. I think it's important
> to start very small. For one, to get familiar with the process, and two, to
> get a baseline for what might be too drastic, based on feedback and things.
>
> Changing a programming language is a big deal, especially for those of us
> who aren't primarily language designers. Let's take baby steps, but not shy
> away completely. I think focusing on specific things that cause annoyances,
> or hesitation to adopt, is a good way to focus and not go too crazy. Let's
> have developers come back to something familiar, but also a little
> improved.
>
> - Josh
>
> On Sep 27, 2016 5:05 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> > I think I expressed clear support for that feature. Please do not read
> > otherwise.
> > I support it, and I agree that it is a step forward, and I also don't
> think
> > it could have any real negative consequences in isolation so long as
> people
> > don't try the new code in an old compiler.
> >
> > My comments were more to provoke thinking of the possible implications of
> > making *numerous* changes to the language. It was not even intended to be
> > read as a reason 'not to do' something, but just to consider
> implications.
> >
> > I too have faced the exact same Event import annoyance so, as I said I
> > would welcome this change for sure. I don't have any personal issue with
> > *any* of this, including the other language features mentioned. Again, I
> > would welcome them for my own use. What I don't know is whether I (you,
> we)
> > acurately represent the bulk of people who would be interested in using
> > FlexJS (I was a marketer in a former career so spent a lot of time
> thinking
> > like this, dissociating my own views about what was 'obvious' from
> > decision-making, and collecting the type of feedback you described before
> > decisions were even made about changing things).
> >
> > I have also seen a number of discussions in the other project I mentioned
> > over the years where there was tension over new features ('complicated'
> vs.
> > 'familiar') so I am really just sharing that part of what I have observed
> > elsewhere.
> >
> > e.g. "How important is familiarity in terms of popularity"
> >
> > If (hypothetically) returning actionscripters will represent the bulk of
> > FlexJS users, will they be daunted by something that is unfamiliar?
> > If (also hypothetically) you knew this to be true, it doesn't mean you
> > can't do things about it, you could plan for it and make it more
> welcoming
> > for them with loads of examples, tutorials, and messages to make sure
> they
> > still felt 'at home' with the language etc. Not doing the right thing
> might
> > 'hinder' growth.
> >
> > The other point I think is not illogical either - the more you become
> > similar to something else that has other advantages (e.g. maturity), the
> > more your points of difference need to be strong (both in terms of their
> > actual implementation and in terms of how you manage their perception,
> the
> > latter not always being front-of-mind for developers).
> >
> > I left marketing because I much prefer the direct cause and effect
> > relationship associated with programming. But that doesn't stop me
> > sometimes from thinking in my old ways. However I shall switch off those
> > neurons now.
> >
> > The answer to all this (adding the extra features like generics and
> enums)
> > might simply be "we can't get distracted by all that other stuff, let's
> do
> > what works well for us". If this still results in a viable and vibrant
> > future for FlexJS, then I am sold.
> >
> >
> >
> > On Wed, Sep 28, 2016 at 11:30 AM, Josh Tynjala <jo...@gmail.com>
> > wrote:
> >
> > > I want to add a small feature that is meant to help developers with a
> > real
> > > annoyance that I have seen repeated complaints about over the years.
> It's
> > > something I've run into myself, as you could see from the Starling
> > examples
> > > I included in my original post. I'm baffled that anyone would say that
> an
> > > optional new feature with this kind of targeted impact could possibly
> > > hinder the cause.
> > >
> > > ActionScript remaining completely stagnant for years is frequently
> stated
> > > as a reason why people choose to stop using it. It's been too long, and
> > > even if the improvements are small, I believe they will be welcomed.
> > Sure,
> > > we might see some "too little, too late" responses, but snarky comments
> > go
> > > with the territory. None of us would still be here if that kind of
> stuff
> > > bothered us.
> > >
> > > Finally, I'm all for comparisons being made to other technologies. If
> > we're
> > > a part of the conversation, it means we're doing something right. It's
> > okay
> > > if some people ultimately choose the other side of the comparison. If
> > > anything, the feedback about why they chose the other option will help
> us
> > > see where we need to improve. We need people talking about FlexJS and
> > > transpiled ActionScript. Even if it's "that's not right for me
> > because...",
> > > they cared enough to say something, and that's actually a big deal, in
> my
> > > opinion.
> > >
> > > - Josh
> > >
> > > On Tue, Sep 27, 2016 at 2:45 PM, Greg Dove <gr...@gmail.com>
> wrote:
> > >
> > > > My 2 cents:
> > > > Haxe as a language already has features like this (and many more) as
> > well
> > > > as being very mature, and not too distant from actionscript.
> > > >
> > > > I see the 'import as' feature as definitely helpful (I would use it
> for
> > > > sure), but I feel that if you tried to make actionscript too much
> like
> > > Haxe
> > > > (which also targets js and swf, along with numerous other targets)
> then
> > > the
> > > > mxml and framework side of things needs to be a very strong point of
> > > > differentiation when others seek to compare Haxe and Falcon/AS. (I
> > think
> > > > there may also be some xml based declarative support libraries for
> Haxe
> > > as
> > > > well, although I have not looked into that).
> > > >
> > > > A couple of things to consider before making changes:
> > > > -How important is familiarity in terms of popularity?
> > > > -The more you encroach on something else with those features, the
> more
> > > you
> > > > will have direct comparisons made. If you get 'too similar', it is I
> > > think
> > > > more likely that the more mature option will 'win' in a comparison.
> > > >
> > > > I like both Haxe and actionscript for different reasons, and I am
> > > > comfortable with liking both (some people tend to be more polar in
> > their
> > > > views!).
> > > > I personally would also welcome these features in actionscript. But I
> > do
> > > > wonder whether it helps or hinders the long term cause.
> > > > </2cents>
> > > >
> > > >
> > > > On Wed, Sep 28, 2016 at 9:40 AM, Christofer Dutz <
> > > > christofer.dutz@c-ware.de>
> > > > wrote:
> > > >
> > > > > 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 <ah...@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" <ch...@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 <jo...@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
> > > > >
> > > > >
> > > >
> > >
> >
>

AW: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Christofer Dutz <ch...@c-ware.de>]

Would also be a great opportunity to eventually cleanup some really anoying quirks in the Language specification ... stuff like if you try to cast to Array, you get a new one containing the input as single element ...


var test:* = ["lalala", "dumdidum"];

var arr:Array = Array(test);

trace(arr);


returns something like this:

[["lalala", "dumdidum"]]


if I do

var test:* = ["lalala", "dumdidum"];

var arr:Array = test as Array;

trace(arr);


I get:

["lalala", "dumdidum"]


I think there were one or two other exceptions, that really really anoy me and probably others too.


Chris

________________________________
Von: Josh Tynjala <jo...@gmail.com>
Gesendet: Mittwoch, 28. September 2016 02:50:12
An: dev@flex.apache.org
Betreff: Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

I agree with your point about numerous changes. I think that's something
that I didn't fully catch when reading your message. I think it's important
to start very small. For one, to get familiar with the process, and two, to
get a baseline for what might be too drastic, based on feedback and things.

Changing a programming language is a big deal, especially for those of us
who aren't primarily language designers. Let's take baby steps, but not shy
away completely. I think focusing on specific things that cause annoyances,
or hesitation to adopt, is a good way to focus and not go too crazy. Let's
have developers come back to something familiar, but also a little improved.

- Josh

On Sep 27, 2016 5:05 PM, "Greg Dove" <gr...@gmail.com> wrote:

> I think I expressed clear support for that feature. Please do not read
> otherwise.
> I support it, and I agree that it is a step forward, and I also don't think
> it could have any real negative consequences in isolation so long as people
> don't try the new code in an old compiler.
>
> My comments were more to provoke thinking of the possible implications of
> making *numerous* changes to the language. It was not even intended to be
> read as a reason 'not to do' something, but just to consider implications.
>
> I too have faced the exact same Event import annoyance so, as I said I
> would welcome this change for sure. I don't have any personal issue with
> *any* of this, including the other language features mentioned. Again, I
> would welcome them for my own use. What I don't know is whether I (you, we)
> acurately represent the bulk of people who would be interested in using
> FlexJS (I was a marketer in a former career so spent a lot of time thinking
> like this, dissociating my own views about what was 'obvious' from
> decision-making, and collecting the type of feedback you described before
> decisions were even made about changing things).
>
> I have also seen a number of discussions in the other project I mentioned
> over the years where there was tension over new features ('complicated' vs.
> 'familiar') so I am really just sharing that part of what I have observed
> elsewhere.
>
> e.g. "How important is familiarity in terms of popularity"
>
> If (hypothetically) returning actionscripters will represent the bulk of
> FlexJS users, will they be daunted by something that is unfamiliar?
> If (also hypothetically) you knew this to be true, it doesn't mean you
> can't do things about it, you could plan for it and make it more welcoming
> for them with loads of examples, tutorials, and messages to make sure they
> still felt 'at home' with the language etc. Not doing the right thing might
> 'hinder' growth.
>
> The other point I think is not illogical either - the more you become
> similar to something else that has other advantages (e.g. maturity), the
> more your points of difference need to be strong (both in terms of their
> actual implementation and in terms of how you manage their perception, the
> latter not always being front-of-mind for developers).
>
> I left marketing because I much prefer the direct cause and effect
> relationship associated with programming. But that doesn't stop me
> sometimes from thinking in my old ways. However I shall switch off those
> neurons now.
>
> The answer to all this (adding the extra features like generics and enums)
> might simply be "we can't get distracted by all that other stuff, let's do
> what works well for us". If this still results in a viable and vibrant
> future for FlexJS, then I am sold.
>
>
>
> On Wed, Sep 28, 2016 at 11:30 AM, Josh Tynjala <jo...@gmail.com>
> wrote:
>
> > I want to add a small feature that is meant to help developers with a
> real
> > annoyance that I have seen repeated complaints about over the years. It's
> > something I've run into myself, as you could see from the Starling
> examples
> > I included in my original post. I'm baffled that anyone would say that an
> > optional new feature with this kind of targeted impact could possibly
> > hinder the cause.
> >
> > ActionScript remaining completely stagnant for years is frequently stated
> > as a reason why people choose to stop using it. It's been too long, and
> > even if the improvements are small, I believe they will be welcomed.
> Sure,
> > we might see some "too little, too late" responses, but snarky comments
> go
> > with the territory. None of us would still be here if that kind of stuff
> > bothered us.
> >
> > Finally, I'm all for comparisons being made to other technologies. If
> we're
> > a part of the conversation, it means we're doing something right. It's
> okay
> > if some people ultimately choose the other side of the comparison. If
> > anything, the feedback about why they chose the other option will help us
> > see where we need to improve. We need people talking about FlexJS and
> > transpiled ActionScript. Even if it's "that's not right for me
> because...",
> > they cared enough to say something, and that's actually a big deal, in my
> > opinion.
> >
> > - Josh
> >
> > On Tue, Sep 27, 2016 at 2:45 PM, Greg Dove <gr...@gmail.com> wrote:
> >
> > > My 2 cents:
> > > Haxe as a language already has features like this (and many more) as
> well
> > > as being very mature, and not too distant from actionscript.
> > >
> > > I see the 'import as' feature as definitely helpful (I would use it for
> > > sure), but I feel that if you tried to make actionscript too much like
> > Haxe
> > > (which also targets js and swf, along with numerous other targets) then
> > the
> > > mxml and framework side of things needs to be a very strong point of
> > > differentiation when others seek to compare Haxe and Falcon/AS. (I
> think
> > > there may also be some xml based declarative support libraries for Haxe
> > as
> > > well, although I have not looked into that).
> > >
> > > A couple of things to consider before making changes:
> > > -How important is familiarity in terms of popularity?
> > > -The more you encroach on something else with those features, the more
> > you
> > > will have direct comparisons made. If you get 'too similar', it is I
> > think
> > > more likely that the more mature option will 'win' in a comparison.
> > >
> > > I like both Haxe and actionscript for different reasons, and I am
> > > comfortable with liking both (some people tend to be more polar in
> their
> > > views!).
> > > I personally would also welcome these features in actionscript. But I
> do
> > > wonder whether it helps or hinders the long term cause.
> > > </2cents>
> > >
> > >
> > > On Wed, Sep 28, 2016 at 9:40 AM, Christofer Dutz <
> > > christofer.dutz@c-ware.de>
> > > wrote:
> > >
> > > > 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 <ah...@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" <ch...@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 <jo...@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
> > > >
> > > >
> > >
> >
>

Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Josh Tynjala <jo...@gmail.com>]

I agree with your point about numerous changes. I think that's something
that I didn't fully catch when reading your message. I think it's important
to start very small. For one, to get familiar with the process, and two, to
get a baseline for what might be too drastic, based on feedback and things.

Changing a programming language is a big deal, especially for those of us
who aren't primarily language designers. Let's take baby steps, but not shy
away completely. I think focusing on specific things that cause annoyances,
or hesitation to adopt, is a good way to focus and not go too crazy. Let's
have developers come back to something familiar, but also a little improved.

- Josh

On Sep 27, 2016 5:05 PM, "Greg Dove" <gr...@gmail.com> wrote:

> I think I expressed clear support for that feature. Please do not read
> otherwise.
> I support it, and I agree that it is a step forward, and I also don't think
> it could have any real negative consequences in isolation so long as people
> don't try the new code in an old compiler.
>
> My comments were more to provoke thinking of the possible implications of
> making *numerous* changes to the language. It was not even intended to be
> read as a reason 'not to do' something, but just to consider implications.
>
> I too have faced the exact same Event import annoyance so, as I said I
> would welcome this change for sure. I don't have any personal issue with
> *any* of this, including the other language features mentioned. Again, I
> would welcome them for my own use. What I don't know is whether I (you, we)
> acurately represent the bulk of people who would be interested in using
> FlexJS (I was a marketer in a former career so spent a lot of time thinking
> like this, dissociating my own views about what was 'obvious' from
> decision-making, and collecting the type of feedback you described before
> decisions were even made about changing things).
>
> I have also seen a number of discussions in the other project I mentioned
> over the years where there was tension over new features ('complicated' vs.
> 'familiar') so I am really just sharing that part of what I have observed
> elsewhere.
>
> e.g. "How important is familiarity in terms of popularity"
>
> If (hypothetically) returning actionscripters will represent the bulk of
> FlexJS users, will they be daunted by something that is unfamiliar?
> If (also hypothetically) you knew this to be true, it doesn't mean you
> can't do things about it, you could plan for it and make it more welcoming
> for them with loads of examples, tutorials, and messages to make sure they
> still felt 'at home' with the language etc. Not doing the right thing might
> 'hinder' growth.
>
> The other point I think is not illogical either - the more you become
> similar to something else that has other advantages (e.g. maturity), the
> more your points of difference need to be strong (both in terms of their
> actual implementation and in terms of how you manage their perception, the
> latter not always being front-of-mind for developers).
>
> I left marketing because I much prefer the direct cause and effect
> relationship associated with programming. But that doesn't stop me
> sometimes from thinking in my old ways. However I shall switch off those
> neurons now.
>
> The answer to all this (adding the extra features like generics and enums)
> might simply be "we can't get distracted by all that other stuff, let's do
> what works well for us". If this still results in a viable and vibrant
> future for FlexJS, then I am sold.
>
>
>
> On Wed, Sep 28, 2016 at 11:30 AM, Josh Tynjala <jo...@gmail.com>
> wrote:
>
> > I want to add a small feature that is meant to help developers with a
> real
> > annoyance that I have seen repeated complaints about over the years. It's
> > something I've run into myself, as you could see from the Starling
> examples
> > I included in my original post. I'm baffled that anyone would say that an
> > optional new feature with this kind of targeted impact could possibly
> > hinder the cause.
> >
> > ActionScript remaining completely stagnant for years is frequently stated
> > as a reason why people choose to stop using it. It's been too long, and
> > even if the improvements are small, I believe they will be welcomed.
> Sure,
> > we might see some "too little, too late" responses, but snarky comments
> go
> > with the territory. None of us would still be here if that kind of stuff
> > bothered us.
> >
> > Finally, I'm all for comparisons being made to other technologies. If
> we're
> > a part of the conversation, it means we're doing something right. It's
> okay
> > if some people ultimately choose the other side of the comparison. If
> > anything, the feedback about why they chose the other option will help us
> > see where we need to improve. We need people talking about FlexJS and
> > transpiled ActionScript. Even if it's "that's not right for me
> because...",
> > they cared enough to say something, and that's actually a big deal, in my
> > opinion.
> >
> > - Josh
> >
> > On Tue, Sep 27, 2016 at 2:45 PM, Greg Dove <gr...@gmail.com> wrote:
> >
> > > My 2 cents:
> > > Haxe as a language already has features like this (and many more) as
> well
> > > as being very mature, and not too distant from actionscript.
> > >
> > > I see the 'import as' feature as definitely helpful (I would use it for
> > > sure), but I feel that if you tried to make actionscript too much like
> > Haxe
> > > (which also targets js and swf, along with numerous other targets) then
> > the
> > > mxml and framework side of things needs to be a very strong point of
> > > differentiation when others seek to compare Haxe and Falcon/AS. (I
> think
> > > there may also be some xml based declarative support libraries for Haxe
> > as
> > > well, although I have not looked into that).
> > >
> > > A couple of things to consider before making changes:
> > > -How important is familiarity in terms of popularity?
> > > -The more you encroach on something else with those features, the more
> > you
> > > will have direct comparisons made. If you get 'too similar', it is I
> > think
> > > more likely that the more mature option will 'win' in a comparison.
> > >
> > > I like both Haxe and actionscript for different reasons, and I am
> > > comfortable with liking both (some people tend to be more polar in
> their
> > > views!).
> > > I personally would also welcome these features in actionscript. But I
> do
> > > wonder whether it helps or hinders the long term cause.
> > > </2cents>
> > >
> > >
> > > On Wed, Sep 28, 2016 at 9:40 AM, Christofer Dutz <
> > > christofer.dutz@c-ware.de>
> > > wrote:
> > >
> > > > 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 <ah...@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" <ch...@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 <jo...@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
> > > >
> > > >
> > >
> >
>

Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove <gr...@gmail.com>]

I think I expressed clear support for that feature. Please do not read
otherwise.
I support it, and I agree that it is a step forward, and I also don't think
it could have any real negative consequences in isolation so long as people
don't try the new code in an old compiler.

My comments were more to provoke thinking of the possible implications of
making *numerous* changes to the language. It was not even intended to be
read as a reason 'not to do' something, but just to consider implications.

I too have faced the exact same Event import annoyance so, as I said I
would welcome this change for sure. I don't have any personal issue with
*any* of this, including the other language features mentioned. Again, I
would welcome them for my own use. What I don't know is whether I (you, we)
acurately represent the bulk of people who would be interested in using
FlexJS (I was a marketer in a former career so spent a lot of time thinking
like this, dissociating my own views about what was 'obvious' from
decision-making, and collecting the type of feedback you described before
decisions were even made about changing things).

I have also seen a number of discussions in the other project I mentioned
over the years where there was tension over new features ('complicated' vs.
'familiar') so I am really just sharing that part of what I have observed
elsewhere.

e.g. "How important is familiarity in terms of popularity"

If (hypothetically) returning actionscripters will represent the bulk of
FlexJS users, will they be daunted by something that is unfamiliar?
If (also hypothetically) you knew this to be true, it doesn't mean you
can't do things about it, you could plan for it and make it more welcoming
for them with loads of examples, tutorials, and messages to make sure they
still felt 'at home' with the language etc. Not doing the right thing might
'hinder' growth.

The other point I think is not illogical either - the more you become
similar to something else that has other advantages (e.g. maturity), the
more your points of difference need to be strong (both in terms of their
actual implementation and in terms of how you manage their perception, the
latter not always being front-of-mind for developers).

I left marketing because I much prefer the direct cause and effect
relationship associated with programming. But that doesn't stop me
sometimes from thinking in my old ways. However I shall switch off those
neurons now.

The answer to all this (adding the extra features like generics and enums)
might simply be "we can't get distracted by all that other stuff, let's do
what works well for us". If this still results in a viable and vibrant
future for FlexJS, then I am sold.



On Wed, Sep 28, 2016 at 11:30 AM, Josh Tynjala <jo...@gmail.com>
wrote:

> I want to add a small feature that is meant to help developers with a real
> annoyance that I have seen repeated complaints about over the years. It's
> something I've run into myself, as you could see from the Starling examples
> I included in my original post. I'm baffled that anyone would say that an
> optional new feature with this kind of targeted impact could possibly
> hinder the cause.
>
> ActionScript remaining completely stagnant for years is frequently stated
> as a reason why people choose to stop using it. It's been too long, and
> even if the improvements are small, I believe they will be welcomed. Sure,
> we might see some "too little, too late" responses, but snarky comments go
> with the territory. None of us would still be here if that kind of stuff
> bothered us.
>
> Finally, I'm all for comparisons being made to other technologies. If we're
> a part of the conversation, it means we're doing something right. It's okay
> if some people ultimately choose the other side of the comparison. If
> anything, the feedback about why they chose the other option will help us
> see where we need to improve. We need people talking about FlexJS and
> transpiled ActionScript. Even if it's "that's not right for me because...",
> they cared enough to say something, and that's actually a big deal, in my
> opinion.
>
> - Josh
>
> On Tue, Sep 27, 2016 at 2:45 PM, Greg Dove <gr...@gmail.com> wrote:
>
> > My 2 cents:
> > Haxe as a language already has features like this (and many more) as well
> > as being very mature, and not too distant from actionscript.
> >
> > I see the 'import as' feature as definitely helpful (I would use it for
> > sure), but I feel that if you tried to make actionscript too much like
> Haxe
> > (which also targets js and swf, along with numerous other targets) then
> the
> > mxml and framework side of things needs to be a very strong point of
> > differentiation when others seek to compare Haxe and Falcon/AS. (I think
> > there may also be some xml based declarative support libraries for Haxe
> as
> > well, although I have not looked into that).
> >
> > A couple of things to consider before making changes:
> > -How important is familiarity in terms of popularity?
> > -The more you encroach on something else with those features, the more
> you
> > will have direct comparisons made. If you get 'too similar', it is I
> think
> > more likely that the more mature option will 'win' in a comparison.
> >
> > I like both Haxe and actionscript for different reasons, and I am
> > comfortable with liking both (some people tend to be more polar in their
> > views!).
> > I personally would also welcome these features in actionscript. But I do
> > wonder whether it helps or hinders the long term cause.
> > </2cents>
> >
> >
> > On Wed, Sep 28, 2016 at 9:40 AM, Christofer Dutz <
> > christofer.dutz@c-ware.de>
> > wrote:
> >
> > > 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 <ah...@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" <ch...@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 <jo...@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
> > >
> > >
> >
>

Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

Couple of thoughts:

Yes, ActionScript is going to be compared against other languages.  We
simply don't want to make that the decision point.  Developer productivity
is what we need to deliver.  MXML and AS are our starting point because
that is what we own.  Really, if folks wanted to glue their MXML together
with TypeScript or Haxe, I would have no problem with folks making that
happen.  Adding features that improve developer productivity are worth
doing.


I guess I'll have to run a test in Java, but the key thing about runtime
type checking and conversion is something like this:

var foo:* = "Test String";
var bar:ArrayList.<String> = foo; // should throw an type-mismatch error
since a single String is not an ArrayList of strings.

Substitute Vector for ArrayList and the Flash runtime will catch it.  Not
sure what we'll generate in ABC so it gets caught.

Then there is:

var foo:ArrayList.<Object> = new ArrayList.<Object>([new
ValueObject("obj1"), new ValueObject("obj2")]);
var bar:ArrayList.<ValueObject> = foo;  // ok
var baz:ArrayList.<String> = foo; // not ok

I always figured Java checked for this at runtime, but maybe not.

-Alex

Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Josh Tynjala <jo...@gmail.com>]

I want to add a small feature that is meant to help developers with a real
annoyance that I have seen repeated complaints about over the years. It's
something I've run into myself, as you could see from the Starling examples
I included in my original post. I'm baffled that anyone would say that an
optional new feature with this kind of targeted impact could possibly
hinder the cause.

ActionScript remaining completely stagnant for years is frequently stated
as a reason why people choose to stop using it. It's been too long, and
even if the improvements are small, I believe they will be welcomed. Sure,
we might see some "too little, too late" responses, but snarky comments go
with the territory. None of us would still be here if that kind of stuff
bothered us.

Finally, I'm all for comparisons being made to other technologies. If we're
a part of the conversation, it means we're doing something right. It's okay
if some people ultimately choose the other side of the comparison. If
anything, the feedback about why they chose the other option will help us
see where we need to improve. We need people talking about FlexJS and
transpiled ActionScript. Even if it's "that's not right for me because...",
they cared enough to say something, and that's actually a big deal, in my
opinion.

- Josh

On Tue, Sep 27, 2016 at 2:45 PM, Greg Dove <gr...@gmail.com> wrote:

> My 2 cents:
> Haxe as a language already has features like this (and many more) as well
> as being very mature, and not too distant from actionscript.
>
> I see the 'import as' feature as definitely helpful (I would use it for
> sure), but I feel that if you tried to make actionscript too much like Haxe
> (which also targets js and swf, along with numerous other targets) then the
> mxml and framework side of things needs to be a very strong point of
> differentiation when others seek to compare Haxe and Falcon/AS. (I think
> there may also be some xml based declarative support libraries for Haxe as
> well, although I have not looked into that).
>
> A couple of things to consider before making changes:
> -How important is familiarity in terms of popularity?
> -The more you encroach on something else with those features, the more you
> will have direct comparisons made. If you get 'too similar', it is I think
> more likely that the more mature option will 'win' in a comparison.
>
> I like both Haxe and actionscript for different reasons, and I am
> comfortable with liking both (some people tend to be more polar in their
> views!).
> I personally would also welcome these features in actionscript. But I do
> wonder whether it helps or hinders the long term cause.
> </2cents>
>
>
> On Wed, Sep 28, 2016 at 9:40 AM, Christofer Dutz <
> christofer.dutz@c-ware.de>
> wrote:
>
> > 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 <ah...@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" <ch...@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 <jo...@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
> >
> >
>

Re: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove <gr...@gmail.com>]

My 2 cents:
Haxe as a language already has features like this (and many more) as well
as being very mature, and not too distant from actionscript.

I see the 'import as' feature as definitely helpful (I would use it for
sure), but I feel that if you tried to make actionscript too much like Haxe
(which also targets js and swf, along with numerous other targets) then the
mxml and framework side of things needs to be a very strong point of
differentiation when others seek to compare Haxe and Falcon/AS. (I think
there may also be some xml based declarative support libraries for Haxe as
well, although I have not looked into that).

A couple of things to consider before making changes:
-How important is familiarity in terms of popularity?
-The more you encroach on something else with those features, the more you
will have direct comparisons made. If you get 'too similar', it is I think
more likely that the more mature option will 'win' in a comparison.

I like both Haxe and actionscript for different reasons, and I am
comfortable with liking both (some people tend to be more polar in their
views!).
I personally would also welcome these features in actionscript. But I do
wonder whether it helps or hinders the long term cause.
</2cents>


On Wed, Sep 28, 2016 at 9:40 AM, Christofer Dutz <ch...@c-ware.de>
wrote:

> 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 <ah...@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" <ch...@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 <jo...@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
>
>

AW: Generics (was: Re: AW: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Christofer Dutz <ch...@c-ware.de>]

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 <ah...@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" <ch...@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 <jo...@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