I’m not going to claim I understand what you just wrote. ;-) I’ll see if I can understand the output…
Thanks. > On Jul 17, 2017, at 10:33 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > Thinking about it more, I think a parameter of type Function never needs > to be wrapped. It would get wrapped on any assignment in the function > body. I just pushed changes to reflect that. > > -Alex > > On 7/16/17, 11:41 PM, "Alex Harui" <aha...@adobe.com.INVALID> wrote: > >> Seems reasonable to add a check to see if the function body is for a >> static method. >> >> -Alex >> >> On 7/16/17, 11:25 PM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> A directive could be a solution. >>> >>> But I think this is an issue with any static method. If a closure is used >>> inside a static method, or a function declared inside a static method, it >>> should not use Language.closure. >>> >>> FWIW, the Google compile complains about “this” being used in a static >>> method as well: >>> >>> [mxmlc] Jul 16, 2017 7:26:08 PM >>> com.google.javascript.jscomp.LoggerErrorManager println >>> [mxmlc] WARNING: >>> /Users/harbs/Documents/ApacheFlex/flex-asjs/examples/flexjs/DebuggingExam >>> p >>> le/bin/js-debug/org/apache/flex/utils/callLater.js:35: WARNING - >>> dangerous use of this in static method org.apache.flex.utils.callLater >>> [mxmlc] >>> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this, >>> 'makeCalls'), 0); >>> >>> Package level functions should be treated as static methods. >>> >>> It might not be a bad idea to add a directive to allow developers to >>> avoid Language.closure calls at will, but I think the “correct” general >>> solution is to never output Language.closure in static and package level >>> functions. >>> >>>> On Jul 17, 2017, at 9:16 AM, Alex Harui <aha...@adobe.com.INVALID> >>>> wrote: >>>> >>>> I don't see any current way to suppress the Language.closure. Without >>>> flow-analysis, I'm not sure the compiler can tell. It could guess that >>>> the identifier is a parameter, but the parameter variable could be >>>> assigned within the function body. >>>> >>>> We could add a new directive like @flexjsisclosure or something like >>>> that. >>>> >>>> Thoughts? >>>> -Alex >>>> >>>> On 7/16/17, 10:05 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>>> >>>>> I figured out the problem. >>>>> >>>>> org.apache.flex.utils.callLater has the following code: >>>>> setTimeout(makeCalls, 0); >>>>> >>>>> That compiles to: >>>>> setTimeout(org.apache.flex.utils.Language.closure(makeCalls, this, >>>>> 'makeCalls'), 0); >>>>> >>>>> When Language.closure is called, it messes up the scope of the calls >>>>> variable and subsequent calls to makeCalls step on each other. I >>>>> believe >>>>> this is because makeCalls is bound to the package object of the >>>>> callLater >>>>> function. >>>>> >>>>> Is there any way to prevent rewriting of function calls to >>>>> Language.closure? >>>>> >>>>> If "setTimeout(makeCalls, 0);" is cross-compiled exactly to: >>>>> "setTimeout(makeCalls, 0);", it works like I’d expect it to. >>>>> >>>>> Thanks, >>>>> Harbs >>>>> >>>>>> On Jul 16, 2017, at 3:46 PM, Harbs <harbs.li...@gmail.com> wrote: >>>>>> >>>>>> Interesting to note: >>>>>> >>>>>> Adding a number of callLater() calls resulted in only the first one >>>>>> being called in JS. I did not try as a SWF. >>>>> >>>> >>> >> >
