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
