> Again, think of the allowed patterns when coming from AS, not all possible JS patterns.
I keep seeing you say something like this, Alex. However, Justin is pointing out perfectly valid AS patterns that are failing in our generated JS. - Josh On Mon, Jun 5, 2017 at 8:37 AM, Alex Harui <aha...@adobe.com.invalid> wrote: > > > 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/ > >
