Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import
From: Harbs <harbs.lists@gmail.com>
In-Reply-To: <CADZSWG6JVjwYEmMR9a=rYDLCuBNwmEY0JUq2-K-Lfx_3BQxxZA@mail.gmail.com>
Date: Wed, 28 Sep 2016 13:25:59 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <F182F695-D57B-4D37-A8ED-6740139070A2@gmail.com>
References: <CADZSWG6JVjwYEmMR9a=rYDLCuBNwmEY0JUq2-K-Lfx_3BQxxZA@mail.gmail.com>
To: dev@flex.apache.org
archived-at: Wed, 28 Sep 2016 10:26:08 -0000

I like this idea and would propose taking it one step further:

Currently transpiled javascript has fully qualified class names for =
pretty much everything. This is difficult for closure to minimize =
completely. I=92d really like to have some way to =93export=94 class =
names as well as =93import=94 to define some compact name for packages. =
Based on my playing around, this could save at least tens of KB of JS =
downloads.

On Sep 27, 2016, at 5:59 PM, Josh Tynjala <joshtynjala@gmail.com> wrote:

> 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.
>=20
> Background
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> 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):
>=20
> // begin example
>=20
> import com.example.ImportedClass;
>=20
> var example:ImportedClass;
>=20
> //end example
>=20
> I would like to make it possible to optionally rename the shortened
> version, like this:
>=20
> // begin example
>=20
> import NewName =3D com.example.ImportedClass;
>=20
> var test:NewName;
>=20
> //end example
>=20
> 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:
>=20
> // begin example
>=20
> import flash.events.Event;
> import starling.events.Event;
>=20
> var one:flash.events.Event;
> var two:starling.events.Event;
>=20
> // end example
>=20
> If we could rename imports, our code wouldn't require cumbersome
> fully-qualified names.
>=20
> Consider the following example, references to FlashEvent will resolve =
to
> flash.events.Event and StarlingEvent will resolve to =
starling.events.Event:
>=20
> // begin example
>=20
> import FlashEvent =3D flash.events.Event;
> import StarlingEvent =3D starling.events.Event;
>=20
> var one:FlashEvent;
> var two:StarlingEvent;
>=20
> // end example
>=20
> 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.
>=20
> // begin example
>=20
> import FlashEvent =3D flash.events.Event;
> import starling.events.Event;
>=20
> var one:FlashEvent;
> var two:Event;
>=20
> // end example
>=20
> 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.
>=20
> Risks and Challenges
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> * 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.
>=20
> 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.
>=20
> 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.
>=20
> Comments welcome.
>=20
> - Josh