You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2019/03/19 10:34:05 UTC
Issue with initialization
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
Re: Issue with initialization
Posted by Carlos Rovira <ca...@apache.org>.
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 (<gr...@gmail.com>)
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 <jo...@apache.org>
> 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 <ha...@gmail.com> 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
Re: Issue with initialization
Posted by Greg Dove <gr...@gmail.com>.
As with most things, there are pros and cons.
For class members, using js-default-initializers=false might make the
startup time marginally better. But it could also reduce runtime
performance (all lookups of undefined properties should, at least in
theory, be slightly slower).
fyi progressive versions of javascript class definitions already have the
opposite approach, where simply mentioning a field name defines it (and
assigns 'undefined' value to it), even without explicitly assigning a
value. This was a planned change in behavior iirc, I think I remember
reading that it was not like that previously. You can see this now in
latest Chrome... (the variable 'default' initialized value is set on the
instance in its constructor, not on its prototype - which is also what I am
used to manually doing when working with react, for example).
to see this, type in browser console:
class Test{myField;}
new Test()
You should see the field in the instance in the console inspector with a
value of undefined. Nothing much there I know, I just wanted to show a
different perspective...
On Wed, Mar 20, 2019 at 7:51 AM Harbs <ha...@gmail.com> wrote:
> 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 <ah...@adobe.com.INVALID>
> 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" <gr...@gmail.com> 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 <jo...@apache.org>
> 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 <ha...@gmail.com> 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
> >>
> >
> >
>
>
Re: Issue with initialization
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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" <gr...@gmail.com> 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 <jo...@apache.org> 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 <ha...@gmail.com> 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
>>
>
>
Re: Issue with initialization
Posted by Josh Tynjala <jo...@apache.org>.
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 <ah...@adobe.com.INVALID> 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" <gr...@gmail.com> 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 <jo...@apache.org> 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 <ha...@gmail.com> 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
> >
>
>
>
Re: Issue with initialization
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@gmail.com> 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 <jo...@apache.org> 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 <ha...@gmail.com> 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
>
Re: Issue with initialization
Posted by Greg Dove <gr...@gmail.com>.
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 <jo...@apache.org> 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 <ha...@gmail.com> 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
>
Re: Issue with initialization
Posted by Josh Tynjala <jo...@apache.org>.
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 <ha...@gmail.com> 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
Re: Issue with initialization
Posted by Josh Tynjala <jo...@apache.org>.
I just pushed a commit where the compiler hoists variables with default initializers.
- Josh
On 2019/03/19 10:34:05, Harbs <ha...@gmail.com> 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