flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] JSHint errors
Date Mon, 27 Jan 2014 21:17:32 GMT
OK thanks. I assume Closure is smart about these assignments?  Otherwise
it seems wasteful to assign the same default value.


On 1/27/14 1:13 PM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:

>In my "other" projects I always assign an initial value to these
>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
>On Mon, Jan 27, 2014 at 8:36 PM, Alex Harui <aharui@adobe.com> wrote:
>> I just tried to clean up some of the JSHint warnings in the JS code
>> 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
>> is the right thing to do with uninitialized variables.  So, what should
>> 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

View raw message