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 <aha...@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 one. > 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.
