Sounds like there is no one right answer, so we should offer choices in
compiler output.
To me, if there are valid and common AS coding patterns that don't require
initialization, I would happily use them and make changes where warnings
detect unsafe usage.
IOW, for
var b:Boolean;
I believe in AS, there is no way to have
if (b === false)
Have any semantically different meaning than
if (b)
This latter pattern is fastest and smallest. If we ever add optimizing to
the compiler, it might the first pattern to the latter.
IMO, we are not here to be able to reproduce every line of JS ever written
by writing AS, we are purposefully limiting the kinds of JS you can write
by making you use AS, so you don't screw yourself over and have improved
developer productivity. We won't let you assign types that mismatch, or
have the wrong number of parameters.
So once you agree that we only want to support AS semantics in JS, then we
can see where we must initialize, and where we might want to offer options.
My 2 cents,
-Alex
On 6/4/17, 6:38 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>Good points. I'm all for initializing more than we do now. Even if we
>don't
>achieve parity with all types, Booleans should definitely default to false
>and Numbers to NaN, if they aren't explicitly initialized with a value, in
>my opinion.
>
>- Josh
>
>On Jun 3, 2017 7:27 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>
>Hi,
>
>So if you run this code on AS
>public var s:String;
>public var o:Object;
>public var i:int;
>public var n:Number;
>public var b:Boolean;
>
>public function init():void {
> trace(s);
> trace(o);
> trace(i);
> trace(n);
> trace(b);
>}
>
>You get:
>null
>null
>0
>NaN
>false
>null
>
>but on JS you get:
>undefined
>undefined
>0
>undefined
>undefined
>undefined
>
>Now with strings, objects and Arrays you can get issues with === and !==
>as
>they are null on one platform and undefined on an another - as discussed
>in
>the other thread.
>
>But the issue is worse with Numbers and Booleans as there are additional
>concerns. Performance is also an issue as JS doesn't know what type they
>are and will be slowed down by implicit casting.
>
>For example this code will not do as you expect and say b is true when it
>is not as undefined != false.
>
>var b:Boolean;
>
>if (b == false)
>{
> trace(“b is false”);
>}
>else
>{
> trace(“b is true”);
>}
>
>Luckily isNaN(undefined) returns true, NaN != undefined so that may cause
>some issues as well.
>
>Thanks,
>Justin
