The GCC is all about optimisation. If it can discard or inline a value
or assignment, it will. The default value may even help give the
compiler (and the developer) additional clues that will allow it to
better optimise the code.
EdB
On Mon, Jan 27, 2014 at 10:17 PM, Alex Harui <aha...@adobe.com> wrote:
> OK thanks. I assume Closure is smart about these assignments? Otherwise
> it seems wasteful to assign the same default value.
>
> -Alex?
>
> On 1/27/14 1:13 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>
>>In my "other" projects I always assign an initial value to these
>>properties.
>>
>>Closure is OK with empty strings and -1 (or whatever) for numbers.
>>
>>For complex types you will have to take into account that the type
>>annotation must match the initial value, e.g. if you want null to be
>>the initial value, the type must allow that, so that would be
>>{?Object} - where the question mark indicates that a null value is
>>allowed.
>>
>>EdB
>>
>>
>>
>>On Mon, Jan 27, 2014 at 8:36 PM, Alex Harui <aha...@adobe.com> wrote:
>>> I just tried to clean up some of the JSHint warnings in the JS code
>>>we've
>>> written for FlexJS. The first thing I ran into was the way we declare
>>> uninitialized variables. An example is:
>>>
>>> /**
>>> * @expose
>>> * @type {string}
>>> */
>>> org.apache.flex.binding.BindingBase.prototype.sourceID;
>>>
>>> The closure linter is ok with this, but JSHint complains, expecting an
>>>"="
>>> and an initial value. I can't find any documentation on what Closure
>>>says
>>> is the right thing to do with uninitialized variables. So, what should
>>>we
>>> do? Should we simply assign null or undefined?
>>>
>>>
>>> -Alex
>>>
>>>
>>
>>
>>
>>--
>>Ix Multimedia Software
>>
>>Jan Luykenstraat 27
>>3521 VB Utrecht
>>
>>T. 06-51952295
>>I. www.ixsoftware.nl
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
