Hi I think as Greg that better to keep this easy as true/false, since don't see user handling grade of granularity
thanks El mar., 19 mar. 2019 a las 19:19, Greg Dove (<[email protected]>) escribió: > 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 > > > -- Carlos Rovira http://about.me/carlosrovira
