flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: Circular Dependencies (was [FalconJX] order of static members)
Date Wed, 20 Jul 2016 10:44:52 GMT
I was waiting until I got my app to run before I responded to this, so my response would be
more intelligent.

On Jul 19, 2016, at 7:13 PM, Alex Harui <aharui@adobe.com> wrote:

> 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.

Now that I have worked through my code, I tend to agree with this statement. Being forced
to work through circularities helped clean up my code.

> Technically, all circularities cause problems.

That’s not what I’m seeing.
With -remove-circulars enabled I ran into the following issues:
1. A super-class could not reference a sub-class at all. I had one case where I had such a
reference to work around an obscure bug. It would have been difficult to work around this
in a more “accepted” way. (I worked-around this pretty easily by using a string representation
of the type name rather than using “is".)
2. A static variable of class A could no reference a class B which somewhere downstream class
B (or its references) have a reference to class A. Changing the static variable in Class A
to in instance variable made this problem go away.
3. Even a private instance variable in class A which references class B using “as” causes
problems when class B has a downstream reference to class A. Using -js-output-optimization=skipAsCoercions
fixed this issue.

That was it. I have plenty of cross-references between two classes both as public and private
getters and none of them caused problems. I’m actually surprised and impressed that I did
not have more issues. Once I wrapped my head around the issues involved, fixing the few issues
I had was pretty straight-foward.

I tried removing the -remove-circulars option, and the only error I was was a circular dependency
of: SEVERE: ERROR - Circular dependency detected: Namespace -> QName -> Namespace

I don’t know if there were others that were not reported because I did not try to fix that

> 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.

Right. That’s the general pattern I use. However, the sub-classes call super.doStuff() as
well to run generic code. My case was a specific problem deep in the generic code (which should
not have happened at all). Trying to extract that logic would have caused a lot of code duplication.
Just excluding the specific sub-class was a simpler ad-hoc solution. Using string class “names”
is what I think is the accepted solution to this situation when overriding is not palatable.

> 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.

I use factories when necessary, but I’m not a big fan of factories when they’re not. I
like to keep indirection down to a minimum.

> 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.

This is a good point, and one I’ll try to keep in mind.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message