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 of
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" wrote:
>Perhaps we can l
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
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.
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" wrote:
>It seems like the
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
var start = Date.now();
var val;
for(var i=0;i<100;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:
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 = tr
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
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 inefficie
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/1 of a % after the Numbers an
Booleans were initialised. I guess google optimisation works in mysterious
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 init
I agree that this is a serious bug.
- Josh
On Jun 9, 2017 10:49 PM, 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
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
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
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
opti
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 = fa
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
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 wrote:
> Thanks for point
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 th
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
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
Hi,
Also how wold you fix this?
if (someBoolean == (complex expression that equals false))
Thanks,
Justin
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
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
Agree with this two, as for the rest I would not touch them.
Piotr
-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-more-on-undefined-non-initialised-values-tp62055p62240.html
Sent from the Apache
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
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 unini
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
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" wrote:
Hi,
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:
u
31 matches
Mail list logo
