flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: git commit: [flex-utilities] [refs/heads/develop] - FLEX-34605 cleanup
Date Sun, 26 Oct 2014 05:17:08 GMT

On 10/25/14, 5:47 AM, "Neil Madsen" <lists@cranialinteractive.com> wrote:

>Same error here.
>Alex, could you add a comment to the file explaining the reason for the
>double "AntClasses"

OK, added a short comment.

>I've never seen it done that way before but after reading your explanation
>it does makes sense.

As you rummage through the SDK code, you’ll see this pattern in other
places.  I think just about every SWC uses this pattern to force-link
classes into the SWC that are not listed in the MXML manifest but are
likely to be used from AS.  For example [1].

It’s a shorthand version of the pattern documented here [2] and saves
defining a variable in the class definition.  But it is a bit subtle so I
should have added a comment back when.

Under the hood, the MXML compiler only links in classes it finds during
the compiling of a class.  The Installer’s Ant_on_AIR library currently
does not have code that causes the linking in of every ant task handler
because I wanted to make it easy for folks who might use Ant_on_AIR in
other scenarios to only have to bake in the ant tasks they need for a
specific purpose.  We can change that if we want, of course.  So that
means the Installer, which doesn’t reference the tasks directly since
really only the Ant script it is executing that needs the task, needs some
way to get all of those tasks linked in.  You don’t actually have to
assign variables with types to link in a class, just mentioning the class
in the package is good enough.




View raw message