On 6/4/17, 1:52 AM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi, > >> Here is a link [1] to you saying "I’m a strong believer in getting it to >> work first, then optimise it, premature optimisation wastes time and >>often >> makes incorrect assumptions.” > >That’s exactly what I’m doing. I has something that works and I want to >improve the performance. > >I’d say making something working 5x as fast, with no other costs, is >hardly premature optimisation. You’re milage of cause may vary. I think everyone is supporting your work dealing with "*" in the CSS code. I haven't looked into it in detail myself, but * is where undefined is allowed in AS so it makes sense in principle. But I'm not sure there is a need to manually scrub places in AS where undefined is not allowed. Changing the compiler output might be the better option. The data you've provided so far in that regard is helpful though. > >> Manually trying to determine whether to use "==" or "===" might be >> better left to tooling someday, so folks don't have to worry about it >>and >> can just get their features to work first. > >Folk will run into this issue right away. Most JS devs use == and !== and >!== instead often evil twins != and ==. > >The current behaviour will confuse people as code that works on JS will >work differently in AS and vice versa. > >> I'd personally lean towards warning when folks use JS patterns that can >>cause trouble. > >What patterns in particular are you referring to here? Sonar cube is >waring about issues in our AS code not JS code. Are you using a Sonar Cube plugin for ActionScript? Using a JS review of AS is likely to be inaccurate, IMO. > >> For uninitialized references to instances, maybe >> leaving it uninitialized and using "== null" is best. > >Unlikely as it’s between 2x and 10x as slow and using == null as opposed >to === null can have unexpected results. I don't remember seeing your test for this. Can you post it again (or a link to the original)? >> Ints are initialized to zero because the common patterns fail if you >> don't, not just because of "==" tests. > >And I think we have the same issue with Booleans and perhaps Numbers. Again, think of the allowed patterns when coming from AS, not all possible JS patterns. > >> But there might be other ways to end up with >> better code than manually scrubbing the source. > >Like what? Please provide data an/or examples and/or facts over option >please. [1] mentions hidden classes. If we can make sure our code leverages these hidden classes, it may turn out that at runtime, there is no difference between "==" and "===" for ints. Thanks, -Alex [1] https://www.html5rocks.com/en/tutorials/speed/v8/
