One of the big use cases to use strict equality is with Numbers and Strings
when you want to exclude 0 and empty strings.
The reason this came up now is based on my work with E4X.
If I’m reading the spec correctly, it differentiates between namespaces with
prefixes which are undefined and prefixes which have an empty string. To test
whether the prefix string is undefined or an empty string, I need strict
equality, and I was not sure as to whether to test for null or undefined.
I guess I can always initialize the prefix of namespaces as null. (i.e. private
var _prefix:String = null;)That will cross-compile correctly. Right?
Actually, I just did some tests with JS and it looks like I’m not totally clear
on how JS handles null and undefined in comparisons:
var a = "";
alert(a==null)//false
alert(""==null)//true
var a = "";
var b;
alert(b==null);//true
alert(b==undefined);//true
alert(b=="");//false
alert(b==a);//false
On Feb 11, 2016, at 12:28 AM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 2/10/16, 1:50 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>
>> Based on a quick test, a member variable on a class that is uninitialized
>> will be undefined with the current JavaScript output. When a member
>> variable is initialized, we currently output that in the constructor, but
>> we don't output any fallback default values for uninitialized members. To
>> me, that seems like it could be considered a bug. Uninitialized member
>> variables should probably have default value (null, NaN, false, or 0,
>> depending on the type).
>
> I agree is is a bug. I'm concerned about the performance implications of
> initializing everything, though. Maybe when we get around to automatic
> type conversion we need to let folks choose levels so they can trade off
> performance.
>
> How many folks use “myObj.someProp === null” where someProp is not of type
> "*"? I think I always use "==". Are you using "===" for speed reasons?
>
> Thanks
> -Alex
>
