FWIW, I got lost understanding why hoisting wasn't good enough and why we would need to specify types in -js-default-initializers. Seems like hoisting should be good enough, and if it is, then we can keep -js-default-initializers as true/false.
My 2 cents, -Alex On 3/19/19, 11:19 AM, "Greg Dove" <[email protected]> wrote: Hi Josh, just a quick comment: re: //only some specific types -js-default-initializers=Boolean,Number I'd prefer that it was kept simple true/false. The only (current) way I can think of to discern dynamic fields on a dynamic class instance is to separate 'known' and 'unknown' fields, so it requires js-default-initializers to be true and applied (through the inheritance chain) of any artbitrary dynamic class instance being inspected at runtime. There is also reflection support to detect this compile setting being on or off. It will become more complicated to do that with different variations, and I am not sure why I would choose only some and not others. Maybe there could be a distinction in scope (class members vs. local variables), but I am still not sure why I would choose that. On Wed, Mar 20, 2019 at 4:17 AM Josh Tynjala <[email protected]> wrote: > It looks like we have a situation where default initialization doesn't > work in the loop because local variables need to be "hoisted" to function > scope. In Flash, the variable would have been initialized before the loop > started, and js-default-initializers will need to implement that behavior. > I will work on that. > > Unfortunately, this issue will affect any type of variable, and not just > the ones that default to null. Boolean, Number, and int/uint will be > affected too. So, it's a bug in how js-default-initializers is implemented, > and not specifically related to variables that are initialized to null. > > Just like false for Boolean, NaN for Number, and 0 for int and uint, > defaulting to null instead of undefined for String, Object, and everything > else preserves the behavior that developers are used to. Technically, only > the * type is supposed to be able to hold the undefined value. > > We could make the exact types that are initialized configurable, I > suppose. Maybe like this: > > //everything > -js-default-initializers=true > > //only some specific types > -js-default-initializers=Boolean,Number > > - Josh > > On 2019/03/19 10:34:05, Harbs <[email protected]> wrote: > > The latest compiler changes exposed a problem: > > > > for(var i:int=0;i<len;i++){ > > var foo:Object; > > if(someCondition(thingy[i]){ > > foo = calculateFoo(thingy[i]); > > } > > doSomethingWithFoo(foo); > > } > > > > Compiles to: > > for(var i=0;i<len;i++){ > > var foo = null; > > if(someCondition(thingy[i]){ > > foo = calculateFoo(thingy[i]); > > } > > doSomethingWithFoo(foo); > > } > > > > This is a change from the intended behavior and foo is nullified in each > step of the loop. This can cause doSomethingWithFoo(null) even when foo was > a valid value in a previous iteration. > > > > I’d suggest two things: > > > > 1. I don’t see the value of initializing Objects to null at all. I’m not > sure why that became the default. I’d vote for not defaulting to > initializing Objects (just other types). > > 2. Local values of any type should not be initialized in a loop. > > > > Harbs >
