flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Just need to vent...
Date Sat, 18 Mar 2017 06:13:46 GMT
Well, I sort of have Harb's suggestion working, then I discovered that the
removal of most of the requires as suggested in #3 means that the
compiler/publisher will have to start copying JS files from the SWCs at
the end of each compile.  Right now, the compiler/publisher checks to see
if the .JS file from a SWC exists in the destination output folder and
doesn't grab a new copy from the SWC, which saves us some time.  The
requires are used to build a dependency tree and once you've removed them,
you have lost information to use in the next compile.

So, does anyone think the we should try to retain the "don't copy if it
exists" code?  Otherwise I will change the code to always copy.  We could
create temporary files in the output folder that record the dependencies
so we don't have to re-compute them, but that's more work than I'd like to
do right now.


On 3/16/17, 8:07 AM, "Alex Harui" <aharui@adobe.com> wrote:

>On 3/16/17, 12:35 AM, "Harbs" <harbs.lists@gmail.com> wrote:
>>I think that’s a good plan.
>>Here’s what (I think) should solve the problem:
>>1. The compiler goes through the require chain once and build a list of
>>all inheritance chains.
>>2. It also builds a list of requires that either have no inheritance, or
>>are at the end of an inheritance chain.
>>3. It removes all requires with the exception of inherited ones, and
>>places the entire list of requires from #2 in the main app class.
>>4. The order of the addDependencies should then not matter with the
>>exception of inheritance chains where the bases need to be at the bottom
>>of the list.
>>The only thing this does not address (unless I’m missing the boat), is
>>static vars and consts. That’s a problem which is I believe is unsolvable
>I thought about doing something like that.  Then I stared wondering if the
>goog.require system was intended to support lazy or just-in-time loading.
>I guess there is no way to interrupt the resolution of goog.requires once
>it starts?
>BTW, for those who like these kinds of logic puzzles, the puzzle is to
>present the three files in an order where the base class is before the sub
>class but the goog.requires do not result in a circularity.  AFAICT, there
>is no way to remove one or more goog.requires and pick an order that
>satisfies these requirements.

View raw message