On 3/16/17, 12:35 AM, "Harbs" <harbs.li...@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 >anyway. 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. -Alex
