You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2017/06/04 02:27:11 UTC
[FlexJS] more on undefined / non initialised values
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
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I believe in AS, there is no way to have
>
> if (b === false)
>
> Have any semantically different meaning than
>
> if (b)
One will check for false the other true so they have opposite meaning. You'll also note I stated “b == false” not “b === false”.
Currently for an uninitialised variable b == false will equal true on AS but false on JS
> This latter pattern is fastest and smallest. If we ever add optimizing to
> the compiler, it might the first pattern to the latter.
I hope not as it will produce a lot of errors.
You’ll also need to consider b == condition where the condition evaluates to false but b is undefined, again you will get the result of true on AS and false on JS.
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <jo...@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" <ju...@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
Re: [FlexJS] more on undefined / non initialised values
Posted by Josh Tynjala <jo...@gmail.com>.
I suspect that the if(b == true) and if(b == false) patterns aren't out of
the ordinary in real-world code. I hope the default will be to initialize
Booleans to false and that you'll need to opt into the other behavior.
- Josh
On Fri, Jun 9, 2017 at 3:38 PM, Alex Harui <ah...@adobe.com.invalid> wrote:
> Thanks for pointing it was == and not ===, but I must still be missing
> something. If a variable is of type Boolean in AS (not JS), is there a
> difference between these three patterns:
>
> If (b)
> If (b == true)
> If (b === true)
>
> Or these three?
>
> If (!b)
> If (b == false)
> If (b === false)
>
> I don't think there is, and so for me, I would rather not have the output
> JS initialize b to false and would rather have the compiler catch were I
> wrote anything other than (b) or (!b). I'd happily replace them and save
> code.
>
> But again, I don't think we have to agree. The compiler can be taught to
> respond to options to initialize everything as well detect unnecessary
> code.
>
> Thanks,
> -Alex
>
> On 6/8/17, 3:40 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> >HI,
> >
> >> Oh. One sec. I actually just tried it in JS and I see that undefined !=
> >>false. That’s weird.
> >
> >Yep that’s the issue.
> >
> >Thanks,
> >Justin
>
>
Re: [FlexJS] more on undefined / non initialised values
Posted by ju...@classsoftware.com.
Hi,
And this particular rabbit hole goes a lot deeper.
Any guesses what these two expression give?
false && undefined
undefined && false
If you expect them to have the same answer you would be incorrect.
Does this matter? Well try this code on both platforms:
var a:Boolean;
var b:Boolean = false;
var c:Boolean = false;
if ((a && b) != c) {
trace("True");
}
else {
trace(“False);
}
You’ll get “False” in the flash player and “True” in JS.
And again this is a simple example the RHS would be a much more complex expression that equates to false and you’ll still have this bug.
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> If a variable is of type Boolean in AS (not JS), is there a
> difference between these three patterns.
No as a boolean can only have the values of true and false and defaults to false in AS.
If you take the same code and run it in the browser it can now have three values, true, false and undefined and it defaults to undefined.
Currently this is cause bugs as undefined != false in JS.
For example this program with incorrectly get "B is true” in the browser and “B is false” in the flash player.
<?xml version="1.0" encoding="utf-8"?>
<js:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:js="library://ns.apache.org/flexjs/basic" applicationComplete="init()">
<js:valuesImpl>
<js:SimpleCSSValuesImpl/>
</js:valuesImpl>
<fx:Script><![CDATA[
protected function init():void
{
var b:Boolean;
if (b == false) {
trace("B is false");
}
else {
trace("B is true");
}
}
]]></fx:Script>
<js:initialView>
<js:View percentWidth="100" percentHeight="100">
</js:View>
</js:initialView>
</js:Application>
It is however a simple example and the same issue will also occur in any case where you end up comparing a freshly defined boolean (i.e. undefined) with an expression that evaluates to false so just converting (b == false) to (!b) would not be enough to solve the issue.
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Thanks for pointing it was == and not ===, but I must still be missing
something. If a variable is of type Boolean in AS (not JS), is there a
difference between these three patterns:
If (b)
If (b == true)
If (b === true)
Or these three?
If (!b)
If (b == false)
If (b === false)
I don't think there is, and so for me, I would rather not have the output
JS initialize b to false and would rather have the compiler catch were I
wrote anything other than (b) or (!b). I'd happily replace them and save
code.
But again, I don't think we have to agree. The compiler can be taught to
respond to options to initialize everything as well detect unnecessary
code.
Thanks,
-Alex
On 6/8/17, 3:40 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>HI,
>
>> Oh. One sec. I actually just tried it in JS and I see that undefined !=
>>false. That’s weird.
>
>Yep that’s the issue.
>
>Thanks,
>Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> Oh. One sec. I actually just tried it in JS and I see that undefined != false. That’s weird.
Yep that’s the issue.
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Harbs <ha...@gmail.com>.
I’m probably missing the point too.
Since an uninitialize boolean would be undefined, undefined == false, so that’s okay.
undefined !== false, so that’s not okay.
Oh. One sec. I actually just tried it in JS and I see that undefined != false. That’s weird. I don’t think I ever realized this (or I forgot it long ago)
so:
var a;
if(a) // is falsy
if(a==true)//falsy
but:
if(a==false)//also falsy
Harbs
> On Jun 9, 2017, at 1:12 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> if (someBoolean === false)
>
> II think you may be missing the point? The issue is with:
>
> if (someBoolean == false)
>
> Not:
>
> if (someBoolean === false)
>
> Thanks,
> Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
If you were wondering about the size here’s the results.
The release version was 1441523 bytes before the change and 1441458 bytes after the change i.e. it become smaller by about 1/10000 of a % after the Numbers an Booleans were initialised. I guess google optimisation works in mysterious ways :-)
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Harbs <ha...@gmail.com>.
var start = Date.now();
var val;
for(var i=0;i<1000000;i++){
val=false;
val=false;
}
console.log(Date.now()-start);
V8 (Node.js and Chrome) seems to optimize this loop out, so you can do a billion iterations really fast. Firefox gives a more realistic indication of performance:
This takes about 700 ms for a million iterations on my machine. Setting it once instead of twice cuts off about 100ms.
Harbs
> On Jun 11, 2017, at 10:56 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
>> 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.
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
So I’ve just checked in a compiler option to turn the initialisers for Number and Boolean off just is case you want to optimise this in other way.
If there are no objections or further suggested changes I’ll merge into develop next week sometime.
YMMV but once merged if you do turn them off it's likely you have less performance and more bugs. I have a couple of these [1] and I’ll send you one :-)
Thanks,
Justin
1. http://shop.evilmadscientist.com/productsmenu/62
Re: [FlexJS] more on undefined / non initialised values
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <pe...@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" <ha...@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 <ju...@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
>>
>
Re: [FlexJS] more on undefined / non initialised values
Posted by Peter Ent <pe...@adobe.com.INVALID>.
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" <ha...@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 <ju...@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
>
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> But I don’t see this as critical for now.
This is probably not required as the google compiler take care of this for us.
Code like this:
function test() {
var a = false;
a = b;
if (a) {
Console.log("got here");
}
}
Becomes:
function test(){b&&Console.log("got here”)}
In this case both assignments are removed.
It even smart enough to turn this:
function test() {
var a = false;
var b = false;
a = true;
if (a && b) {
Console.log("got here");
}
}
Into nothing.
function test(){}
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Harbs <ha...@gmail.com>.
Justin seems to have observed the Google compiler stripping these out. It seems like a good idea to do some research on how extensively it does so. If we can rely on goog to do this work for us, then I’m fine with that.
Either way, the performance implications one way or the other are miniscule. I see this as a “nice to look into” feature for one day when there’s cycles for it, but for now I have plenty of bigger fish to fry. ;-)
We should probably capture this in a JIRA though.
> On Jun 12, 2017, at 7:19 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yep. We are introducing "just-in-case" code. These changes are not PAYG,
> until we get more of these optimizations in. I'm still interested in how
> many of these cases there are. Some day I'll find out. But probably not
> right away.
>
> -Alex
>
> On 6/11/17, 1:21 AM, "Harbs" <ha...@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 <ju...@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
>>
>
Re: [FlexJS] more on undefined / non initialised values
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yep. We are introducing "just-in-case" code. These changes are not PAYG,
until we get more of these optimizations in. I'm still interested in how
many of these cases there are. Some day I'll find out. But probably not
right away.
-Alex
On 6/11/17, 1:21 AM, "Harbs" <ha...@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 <ju...@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
>
Re: [FlexJS] more on undefined / non initialised values
Posted by Harbs <ha...@gmail.com>.
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 <ju...@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
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Re: [FlexJS] more on undefined / non initialised values
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I never said it wasn't important/serious. I did not say it is an
optimization issue.
The changes you made look fine. Seems like eventually we'll have to
initialize other types as well. It makes every variable be like every
airline passenger going through the metal detector. Safe, but inefficient
at times. There are other options out there that are less safe and more
efficient in certain scenarios. That's how optimization often works. It
detects certain patterns and optimizes for them. Me, I'd happily change
the way I write code in order to leverage these optimizations. Some folks
will agree, some won't, doesn't matter, there'll be options to control the
output.
-Alex
On 6/10/17, 8:12 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>So to summarise this thread.
>- discussing if Boolean be initialised to false and Numbers to NaN
>- Code can act differently on AS and JS when these initialisers are not
>present
>- Josh and I think this a serious bug
>- Harbs also sees the issue
>- Piotrz also wants Booleans and Numbers to be initialised
>- Alex thinks this is an optimisation issue
>
>I’ve went ahead and made the change and checked into a new initialization
>branch of falcon.
>
>Testing with a real world application gave no notable size increase and
>improved performance by 10% on JS. Mostly I would guess due to use of ==
>and != in the framework and implicit casting that goes on when when
>comparing uninitialised variables.
>
>Thanks,
>Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
So to summarise this thread.
- discussing if Boolean be initialised to false and Numbers to NaN
- Code can act differently on AS and JS when these initialisers are not present
- Josh and I think this a serious bug
- Harbs also sees the issue
- Piotrz also wants Booleans and Numbers to be initialised
- Alex thinks this is an optimisation issue
I’ve went ahead and made the change and checked into a new initialization branch of falcon.
Testing with a real world application gave no notable size increase and improved performance by 10% on JS. Mostly I would guess due to use of == and != in the framework and implicit casting that goes on when when comparing uninitialised variables.
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Josh Tynjala <jo...@gmail.com>.
I agree that this is a serious bug.
- Josh
On Jun 9, 2017 10:49 PM, <ju...@classsoftware.com> wrote:
> Hi,
>
> I think we may be talking cross purposes here to be clear - IMO this is
> not an optimisation issue this it’s a serious bug.
>
> Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by ju...@classsoftware.com.
Hi,
I think we may be talking cross purposes here to be clear - IMO this is not an optimisation issue this it’s a serious bug.
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> The general principle is optimization. Optimization looks for specific
> patterns. What you wrote below is not one of the patterns.
Not one of what patterns?
BTW Initialising the Boolean to false also optimises the seed by a factor of two. i.e. twice as fast.
> Would be fun to see how often that pattern exists though.
From a quick glance (not testing)it exists in serval places in the existing SDK.
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Alex Harui <ah...@adobe.com.INVALID>.
The general principle is optimization. Optimization looks for specific
patterns. What you wrote below is not one of the patterns. Would be fun
to see how often that pattern exists though. IMO, it would not make sense
to initialize every boolean because 1% of the boolean expressions require
optimization if alternative patterns exist that allow for smaller code.
But again, we don't have to agree, just provide compiler options.
-Alex
On 6/8/17, 3:17 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>Also how wold you fix this?
>
>if (someBoolean == (complex expression that equals false))
>
>Thanks,
>Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Also how wold you fix this?
if (someBoolean == (complex expression that equals false))
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> if (someBoolean === false)
II think you may be missing the point? The issue is with:
if (someBoolean == false)
Not:
if (someBoolean === false)
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Alex Harui <ah...@adobe.com.INVALID>.
It sounds like there are differing opinions. Some folks want all booleans
to be initialized to false, just in case someone uses a pattern like:
if (someBoolean === false)
I would rather find where I've written that pattern so I can manually
change it to:
if (!someBoolean)
since there is no semantic difference in AS. And then I can avoid the
expense of initializing boolean variables.
We don't have to agree. We can teach the compiler to do both.
-Alex
On 6/7/17, 5:23 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> Booleans should definitely default to false and Numbers to NaN, if
>>they aren't explicitly initialized with a value
>
>Anyone have a differing option?
>
>Thanks,
>Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by piotrz <pi...@gmail.com>.
Agree with this two, as for the rest I would not touch them.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-more-on-undefined-non-initialised-values-tp62055p62240.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] more on undefined / non initialised values
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Booleans should definitely default to false and Numbers to NaN, if they aren't explicitly initialized with a value
Anyone have a differing option?
Thanks,
Justin
Re: [FlexJS] more on undefined / non initialised values
Posted by Josh Tynjala <jo...@gmail.com>.
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" <ju...@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