> I actually think this parity is more important than any performance > improvements. I agree with that. Although, I have two minds on this. I wrote my counter-argument to my own arguments after this email (which was making the same point you are making). However, after thinking about this some more, I’m not sure that the SWF behavior is actually desirable. Adding an uninitiated object to a Number is probably symptomatic of a bug. Getting a result of NaN is probably better than the null object resolving to 0.
Whether or not to initialize objects as null is a point of controversy in the Javascript community: https://basarat.gitbooks.io/typescript/docs/tips/null.html <https://basarat.gitbooks.io/typescript/docs/tips/null.html> The performance argument is a non-starter. If you look at the results on the ticket, some browsers perform better on undefined and non-strict equality, but browser performance is a moving target and micro-optimizing against that one way or another is a waste of time. Neither strict equality (on objects of the same type) or initializing objects is INHERENTLY more efficient. In fact, it’s quite possible that undefined is inherently more efficient than null (being that a more basic JS type — but I’m not sure about that). I’m fine discussing the pros and cons of initializing values and strict equality, but let’s please keep performance out of the discussion because it only creates noise. The only thing that I’m fighting is the noise. Personally, my current thinking that not initializing values and using non-strict equality is the better way to go with Framework code. I have no issues making initialization an option for the compiler. My personal preference would be to have two options: 1. A preference to initialize booleans and this should be on by default. 2. A separate preference to initialize all other types (with the possible exception of ints which should go into the same bucket as booleans) which should be off by default. If most folks want to use strict equality in Framework code and initialize objects, I will not put up a fuss. Thanks, Harbs > On Jun 25, 2017, at 7:39 PM, Josh Tynjala <joshtynj...@gmail.com> wrote: > > I should make clear that even though I said "at the very least", which > might sounds like it's minor, I actually think this parity is more > important than any performance improvements. > > - Josh > > On Jun 25, 2017 9:36 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > >> I have yet to hear a good reason not to default to null either. Why are >> you fighting this so hard? All of your arguments that I can recall seem to >> be that Justin's performance claims aren't as big as he says. Is there more >> that I missed? Because if it's little more than that, then, at the very >> least, it's good to improve parity between JS and SWF. >> >> - Josh >> >> >> On Jun 24, 2017 11:45 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >> Not unless you can demonstrate there’s a good reason to do so. I have yet >> to see that. >> >>> On Jun 24, 2017, at 5:45 AM, Justin Mclean <jus...@classsoftware.com> >> wrote: >>> >>> Are you OK for Objects and Strings to default to null as well? >> >> >>
