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