• Julian
    link
    fedilink
    91 year ago

    Ok some of these I understand but what the fuck. Why.

    • @[email protected]
      link
      fedilink
      4
      edit-2
      1 year ago

      I’m not sure if you really want to know, but:

      greater than, smaller than, will cast the type so it will be 0>0 which is false, ofcourse. 0>=0 is true.

      Now == will first compare types, they are different types so it’s false.

      Also I’m a JavaScript Dev and if I ever see someone I work with use these kind of hacks I’m never working together with them again unless they apologize a lot and wash their dirty typing hands with… acid? :-)

      edit: as several people already pointed out, my answer is not accurate. The real solution was mentioned by mycus

      • @[email protected]
        link
        fedilink
        21 year ago

        Not a JavaScript dev here, but I work with it. Doesn’t “==” do type coercion, though? Isn’t that why “===” exists?

        As far as I know the operators “>=” and “<=” are implemented as the negation of “<” and “>” respectively. Why: because when you are working with sticky ordered sets, like natural numbers, those operators work.

        Thus “0<=0” -> “!(0>0)” -> “!(false)” -> “true”

        Correct me if my thinking is wrong though.

  • @TwilightKiddy
    link
    5
    edit-2
    1 year ago

    This one is one of my favourite JS quirks:

    JS quirk

      • @TwilightKiddy
        link
        11 year ago

        parseInt() takes string as an input. From first character, it goes on till it hits a non-digit character, and then converts resulting string to an integer. JS is not strictly-typed, so, when I feed it a floating point number, it implicitly converts it to string. Things like 0.01 it converts like "0.01", no problem here, our first character is zero, and then there is a dot, that’s not a digit, so we parse "0" to integer and get our zero. But at some point it switches to scientific notation when converting to string, so, our 0.0000001 becomes "1E-7". Then we take one as our first character, stop at E as it’s not a digit and we get "1" parsed to one. Praise the loosly-typed hell.

  • sheetmulch
    link
    fedilink
    21 year ago

    I had a fun bug where unit tests started failing on an upgrade. Turns out someone was returning undefined from a comparator. Wtf, people.

  • @[email protected]
    link
    fedilink
    11 year ago

    I wrote an exam about this stuff yesterday.

    In J’s equality is usually checked in a way that variables are casted to the type of the other one. “25” == 25 evaluates to truey because the string converted to int is equal to the int and the other way around.

    You can however check if the thing is identical, using “25” == 25 which skips type conversion and would evaluate as false.

    I assume the same thing happens here, null is casted to int, which gets the value 0.

  • Björn Tantau
    link
    fedilink
    01 year ago

    Can someone explain this? I mean, the last result. Usually I can at least understand Javascript’s or PHP’s quirks. But this time I’m stumped.

    • mycus
      link
      fedilink
      2
      edit-2
      1 year ago

      JS null and undefined shenanigans


      basically:

      1. bigger an lesser comparison types convert null to zero, so is zero bigger than zero? no
      2. == is fucky and to it null only equals undefined and undefined only equals null, so no
      3. is zero bigger than or equal to zero? yeah
    • omnislayer88
      link
      fedilink
      11 year ago

      My only thought here might be >= is usually the same as !< and maybe thats how it is defined in javascript and since < is false than >= == !false == true

  • @[email protected]
    link
    fedilink
    01 year ago

    I know it’s a joke, but it’s an old one and it doesn’t make a lot of sense in this day and age.

    Why are you comparing null to numbers? Shouldn’t you be assuring your values are valid first? Why are you using the “cast everything to the type you see fit and compare” operator?

    Other languages would simply fail. Once more JavaScript greatest sin is not throwing an exception when you ask it to do things that don’t make sense.

    • @[email protected]OP
      link
      fedilink
      11 year ago

      Shouldn’t you be assuring your values are valid first?

      Step 1: Get to prod

      Step 2-10: Add features

      Step 11: Sell the company before it bites you