Sounds like the Google Closure compiler can optimize out unnecessary
initialization, so I think the plan of finishing up adding initialization
is the right change for the our compiler.
At least, that how I understand the situation,
-Alex
On 6/12/17, 8:16 AM, "Peter Ent" <p...@adobe.com.INVALID> wrote:
>Perhaps we can look to other languages for guidance. For example, in
>Swift:
>
>var val:Boolean
>
>is illegal. It MUST be initialized or declared to be optional:
>
>var val:Boolean = false
>var val:Boolean?
>
>The Swift people felt that leaving variables uninitialized and defaulted
>caused too many issues and so force values to be given. If you don't have
>a value then you must declare it to be optional, in which case its value
>is nil until it is assigned a value.
>
>Neither AS nor JS has the luxury of syntax that enforces this, but perhaps
>we could have the compiler issue a warning (at least) that scalar values
>are uninitialized.
>
>‹peter
>
>On 6/11/17, 4:21 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>>It seems like the general case is better to have the initialization.
>>Thanks for implementing that.
>>
>>It would probably be nice for the compiler to be intelligent and only
>>initialize if the code does not initialize too.
>>
>>So:
>>
>>var val:Boolean;
>>// further down before val is actually accessed
>>val = true;// or val = false;
>>
>>should not initialize val, but:
>>
>>var val:Boolean;
>>// further down
>>if(val == someotherval){
>>// do something
>>}
>>should initialize it.
>>
>>But I don¹t see this as critical for now.
>>
>>Harbs
>>
>>> On Jun 11, 2017, at 10:56 AM, Justin Mclean <jus...@classsoftware.com>
>>>wrote:
>>>
>>> Hi,
>>>
>>>> The changes you made look fine.
>>>
>>> Do you want them as the default and an option to turn them off? I¹m
>>>assuming you will you at some later point add other switches to turn
>>>other optimisations (whatever they may be) on?
>>>
>>>> Seems like eventually we'll have to initialize other types as well.
>>>
>>> I¹d guestimate there would be a performance boost for string and for
>>>object as well / but the size cost may be different. Won't know until I
>>>or someone tries it.
>>>
>>>> Safe, but inefficient at times.
>>>
>>> So far I not seen any inefficiency in fact the opposite. But sure there
>>>may be specific cases that perform better, please post any you find to
>>>the list.
>>>
>>> Thanks,
>>> Justin
>>
>
