Harbs expressed a preference for undefined instead of null, so I presented a possible option where the default initializers could be limited to subset of types. I too would prefer true/false only.
I am working on the hoisting. I have it implemented locally, and I'm now adjusting some tests to match the new output. - Josh On 2019/03/19 18:24:11, Alex Harui <[email protected]> wrote: > 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 > > > > >
