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 <christofer.d...@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 <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
> > > > >
> > > > >
> > > >
> > >
> >
>
