I did wonder if this stuff could be refactored so that different parts of the output were buffered and then output in sequence at the end instead of having to use the postProcess approach, although I have no idea what implications that might have for memory or speed. Does that make any sense?
On Fri, Sep 30, 2016 at 11:38 AM, Greg Dove <greg.d...@gmail.com> wrote: > I was seeing examples of situations where new 'usedNames' were being added > during the output of the js but were not captured in the goog.requires > output. > > This caused 'x is undefined' sometimes so that is what I was trying to > address. > I don't have time right now, but I can come back to this later in my day > (midday Friday right now for me). > > Perhaps if you comment out the 'namesToAdd' stuff in postProcess it might > behave like it was reverted and you can check if that removes the Strand > problem. > > > > > On Fri, Sep 30, 2016 at 11:29 AM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 9/29/16, 3:18 PM, "Greg Dove" <greg.d...@gmail.com> wrote: >> >> >That's almost like a dependency analysis pass within the class itself >> >isn't >> >it? To rearrange the ordering, I mean. >> >> I think it means determining the difference between scalar and non-scalar >> initializer values. We already do something like this for instance >> properties. Static properties can be initialized to scalar values in any >> order, but any initial values as a result of function calls and other >> lookups should be run in a class initializer in which case order in the >> source file might always be right, or at least more right than what we >> have now. When to kick off the class initializer is an interesting >> question. Flash runs the class initializer from the verifier. There is >> essentially no such thing for JS. Running all class initializers at >> startup is an undesirable solution. >> >> > >> >If I can see a quick solution to the above I might add it today, but >> >perhaps it is better to wait and try to figure out the bigger problem. >> >> If you still have some time, I'm about to start digging into the >> re-introduction of circular dependencies in the examples like >> DataBindingExample. I suspect the new code you added to the postProcess >> but have no proof yet. If you look at Strand.js, it has a goog.require >> for IBead, but there is no reference to IBead in Strand.js. The String >> 'Ibead' is in the reflection data, but not a reference to the class. I'm >> pretty sure Strand shouldn't require IBead. I'm wondering what cases you >> ran into that caused the new code in postProcess. >> >> Thanks, >> -Alex >> >> >
