For the bug, hoisting is good enough. I was just stating that I don’t see a good reason to initialize generic Objects and types as null instead of undefined.
The only case I’m aware of where that makes a practical difference is strict comparison to null. (i.e. foo === null) I don’t know why you’d do that… I’d personally like the ability to turn off initialization for non built-in types. That could just be an additional compiler option: -js-initialize-null. Basically I’d want all initialization *except* null. My $0.02, Harbs > On Mar 19, 2019, at 8:24 PM, 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 >> > >
