On 7/19/16, 1:54 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>It’s taken me a bit of time to wrap my head around the issues here, but I
>think I have it clear enough to articulate the issues I’m bumping into
>and possibly propose some solutions.
>
>There are two different scenarios related to circulars; debug builds and
>release builds.
>
>Debug Builds:
>I’ve run into two situations where I’ve had errors in the debug build due
>to circularities:
>
>Snip...
>
>As I understand it, the problem with my suggestion is that it does not
>address limitations in the Google Closure Compiler. This brings us to
>release builds.
FWIW, Google doesn't call it a limitation. They think they are enforcing
good design principles. We could generate different code, but it will be
a bunch of work and I don't know if it will have side-effects and GCC will
have trouble optimizing it.
>
>Release Builds:
>There’s many kinds of circularities, I’m I’m not clear on which ones
>cause problems.
Technically, all circularities cause problems. GCC wants to understand
every reference in your source files when optimizing and expects the
goog.requires to define some of the references. And then if the
references are circular, it complains. And while we've provided options
in the compiler to not generate some references, if your code still makes
such a reference without a goog.require for it, you will likely get an
error as well and the optimizer will not generate a release version.
>Alex wrote an explanation on the wiki,[1] which is a good starting point,
>but there’s still questions I have. I will list the ones that I’ve
>thought of:
>
>1. A extends B and B extends A. This is not supported by ActionScript, so
>it’s a non-issue.
>2. Super classes which have a reference to the sub class as mentioned in
>the wiki.
>3. Classes which are unrelated in hierarchy, but reference each other.
>4. A circular chain of class references. (i.e. a uses b which uses c
>which used d which uses a)
>3. public static variables
>4. private static variables
>5. public variables
>6. private variables
>7. function parameters of all four types
>8. function return types.
>9. interfaces.
Apparently, computer scientists have defined patterns for eliminating
circularities. I am not an expert on these patterns since we could get
away with them in Flex/Flash, but below is how I think of the scenarios.
>
>To make this a bit more concrete, I have a number of known circularities
>in my code:
>
>1. I have a sub class which calls a super method to take care of most if
>the object setup. This setup is identical for all sub classes with the
>exception of on piece which should be not done for a specific sub, so in
>the super class I have a line of code if(this is Sub){//don’t do it}.
>Getting rid of this line of code is doable, but would require indirection
>which I’d rather avoid. (but not too big a deal)
IMO, there should be a overridable method where the subclass takes care of
whatever set up it needs. The Base should not know about the Subs as that
makes Base a candidate for updating if a new Sub is needed in the future.
>2. I have a “page” class which keeps track of all objects that it
>contains. The object classes each have a reference to their containing
>pages which is needed to do all kinds of calculations. I think this is a
>totally valid design, and doing it any other way would be very messy and
>make it very difficult to follow the code flow. This exact situation is
>mentioned in the closure lib Google Group.[2]
You can keep track of instances created, but the Page class should only
think of them as Pages and not subclasses of Pages. When I took a look at
your code, I thought I saw the circular reference caused by the base class
taking information and deciding which subclass to create. AIUI, that is
the Factory pattern and that code should be moved to a Factory class and
that should break the circularity and not be too much effort.
>3. I probably have lots of chained dependencies — especially with regard
>to ApplicationFacade.
>
>I don’t know the best way to fix my problems with things as they stand.
>There were two suggestions to problem #2 on the Google Group.[3] One way
>to put the classes in the same file, and the second was to use
>interfaces. My question is whether interfaces would solve the problem:
AIUI, the recommended pattern is that interfaces should not have
references to non-interfaces. And while you can still create
circularities that way, I think the argument is that you can always define
one more interface to break the circularity and that is a better design.
And, FWIW, having no non-interfaces in interfaces and more interfaces
would have helped Flex immensely around the mixing of different versions
of code (the Marshall Plan), so doing this now for FlexJS is a good bet
for our long term future.
HTH,
-Alex
