Re: Circular dependencies (was: Re: Closure compiler CompilationLevel)

[Andy Dufilie <an...@gmail.com>]

On Thu, Dec 31, 2015 at 2:42 AM, Alex Harui <ah...@adobe.com> wrote:

>
> On 12/30/15, 10:31 PM, "Andy Dufilie" <an...@gmail.com> wrote:
> >- When I run flexjs/js/bin/compc I get a bin-release folder with the JS
> >output files.  I then try to run closure manually on these files, and I
> >get
> >circular dependency errors for my code that do not appear when using
> >flexjs/js/bin/mxmlc. Is there an additional step that happens behind the
> >scenes, removing circular dependencies?
>
> Yes.  GoogDepsWriter does that.  Unless you are porting existing libraries
> and it is important to retain the APIs, you might want to consider
> designing libraries to not have circular dependencies.  I don't want to
> make that a hard rule so we try to handle circularities, and there is an
> open JIRA to try a more sophisticated scheme of handling circularities.
>
>
I'm porting a code base that is nearly 100,000 lines of code. The entire
project is over 200,000 lines, but I'm only porting the non-GUI code. Every
time I remember having a circular dependency it turned into a runtime
problem that the compiler couldn't help me with. For example, a static
instance of an object wouldn't get created because a class is unavailable
during static initialization due to a circular dependency. I would actually
prefer if the compiler treated circular dependencies as errors instead of
trying to force things to work.  Errors showing "A -> B -> C -> A" helped
me resolve some issues that I didn't know existed. I'd recommend making
removeCirculars() available as an option, but not the default.

Thanks for listing specific source files and their purpose - very helpful
for someone like me who wants to contribute but isn't familiar with the
architecture.

Andy

Re: Circular dependencies (was: Re: Closure compiler CompilationLevel)

[Alex Harui <ah...@adobe.com>]

FWIW, the compiler currently generates a set of goog.requires based on the
set of class dependencies a source file needed to resolve in order to
compile a file, but IMO that is often a larger set of requires than is
actually needed by the goog.requires subsystem and by the JS runtimes.

For example the following code:

	var foo:SomeClass;

causes FalconJX to generate goog.requires for "SomeClass", however,
technically, I don't believe it is needed since the JS output is:

	var /** @type {SomeClass} */ foo;

This JS output file doesn't actually need to have SomeClass loaded before
it gets loaded.  Only the file with code that actually instantiates a
SomeClass or maybe does a type-check on SomeClass needs to have that
goog.require.  So my next attempt at dealing with circularities will try
to reduce the goog.requires to those actually needed and see if that
reduces the set if circularities.

FWIW, I think there is a good place in GoogDepsWriter to report that a
class has been seen before, but it might be trickier to report the
circular chain since I think it can be quite complex.

Another thought I had was to try to provide an option to move all
goog.requires to the first script loaded.  That might eliminate some
circularities, but not all since you still have to pick an order to load
things.

-Alex

On 1/4/16, 9:43 PM, "Andy Dufilie" <an...@gmail.com> wrote:

>On Thu, Dec 31, 2015 at 2:42 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>> On 12/30/15, 10:31 PM, "Andy Dufilie" <an...@gmail.com> wrote:
>> >- When I run flexjs/js/bin/compc I get a bin-release folder with the JS
>> >output files.  I then try to run closure manually on these files, and I
>> >get
>> >circular dependency errors for my code that do not appear when using
>> >flexjs/js/bin/mxmlc. Is there an additional step that happens behind
>>the
>> >scenes, removing circular dependencies?
>>
>> Yes.  GoogDepsWriter does that.  Unless you are porting existing
>>libraries
>> and it is important to retain the APIs, you might want to consider
>> designing libraries to not have circular dependencies.  I don't want to
>> make that a hard rule so we try to handle circularities, and there is an
>> open JIRA to try a more sophisticated scheme of handling circularities.
>>
>>
>I'm porting a code base that is nearly 100,000 lines of code. The entire
>project is over 200,000 lines, but I'm only porting the non-GUI code.
>Every
>time I remember having a circular dependency it turned into a runtime
>problem that the compiler couldn't help me with. For example, a static
>instance of an object wouldn't get created because a class is unavailable
>during static initialization due to a circular dependency. I would
>actually
>prefer if the compiler treated circular dependencies as errors instead of
>trying to force things to work.  Errors showing "A -> B -> C -> A" helped
>me resolve some issues that I didn't know existed. I'd recommend making
>removeCirculars() available as an option, but not the default.
>
>Thanks for listing specific source files and their purpose - very helpful
>for someone like me who wants to contribute but isn't familiar with the
>architecture.
>
>Andy