• Victor@lemmy.world
    321·
    7 months ago

    In node, I get the same result in both cases. "[object Object]"

    It’s calling the toString() method on both of them, which in the array case is the same as calling .join(",") on the array. For an empty array, that results in an empty string added to "[object Object]" at either end in the respective case in the picture.

    Not sure how we’d get 0 though. Anybody know an implementation that does that? Browsers do that maybe? Which way is spec compliant? Number([]) is 0, and I think maybe it’s in the spec that the algorithm for type coercion includes an initial attempt to convert to Number before falling back to toString()? I dunno, this is all off the top of my head.

    • PoolloverNathan@programming.dev
      34·
      7 months ago

      The inspector REPL evaluates as a statement-with-value (like eval), so the {} at the beginning is considered an empty block, not an object. This leaves +[], which is 0. I don’t know what would make Node differ, however.

      Edit: Tested it myself. It seems Node prefers evaluating this as an expression when it can, but explicitly using eval gives the inspector behavior:

      • Victor@lemmy.world
        15·
        7 months ago

        So there’s yet another level of quirkery to this bullshit then, it seems. 😆 Nice digging! 🤝

        I also noticed that if you surround the curlies with parentheses, you get the same again:

        > eval('{} + []')
0
> eval('({}) + []')
'[object Object]'
        • PoolloverNathan@programming.dev
          8·
          7 months ago

          Yep, parentheses force {} to be interpreted as an expression rather than a block — same reason why IIFEs have !function instead of just function.

          • Victor@lemmy.world
            1·
            7 months ago

            I thought IIFE’s usually looked like (function (...params) {})(...args). That’s not the latest way? To be honest I never used them much, at least not after arrow functions arrived.

  • orangeboats@lemmy.world
    192·
    7 months ago

    This is why I try my damnedest not to write in weakly typed languages.

    string + object makes no logical sense, but the language will be like “'no biggie, you probably meant string + string so let’s convert the object to string”! And so all hell breaks loose when the language’s assumption is wrong.

    • zalgotext@sh.itjust.works
      31·
      7 months ago

      You don’t necessarily need types for that kind of thing though, a strict linter that flags that code works just as well

    • Blackmist@feddit.ukEnglish
      1·
      7 months ago

      Some automatic conversion is fine.

      a=3+0.2

      print(“Hello {name}. You are {age} years old”)

      That kind of thing. But the principle of least surprise definitely applies. If you get to the point where you’re adding two booleans and a string, I feel like the language should at least say something. At least until the technology exists for it to physically reach out of your screen and slap you.

    • dejected_warp_core@lemmy.world
      8·
      7 months ago

      I take this as less of a “I can’t use this intuitive feature reliably” thing and more of a “the truth table will bite you in the ass when you least expect it and/or make a mistake” thing.

      • flying_sheep@lemmy.ml
        51·
        7 months ago

        Just use a formatter. It’ll show you that the second one is two statements:

        1. {} (the empty block)
        2. +[] coerce an empty array to a number: new Number(new Array())
        • dejected_warp_core@lemmy.world
          1·
          7 months ago

          I totally get that: use the right tools and you’ll be okay. This applies to many technologies in this space.

          With respect, I still take this advice like hearing “look out for rattlesnakes if you’re hiking there.” It might be safer to just hike where there are no rattlesnakes, instead.

          • flying_sheep@lemmy.ml
            1·
            7 months ago

            You’re right, of you have compete freedom, do that. If the place you want or need to go to is most comfortably reachable via rattlesnake road, bring boots.

            In other words, if you don’t think the wasm landscape is mature enough to build a web thing with it, you are stuck with JavaScript, but you don’t have to rawdog it. I haven’t run in a single weird thing like this in years of writing typescript with the help of its type system, ESLint and a formatter.

    • marcos@lemmy.world
      21·
      7 months ago

      It’s not even the coercion that is the problem here. The types are already bad by themselves.

    • bahbah23@lemmy.world
      171·
      7 months ago

      I’ve read different defenses for JavaScript for cases like this, which usually runs somewhere from you shouldn’t be doing that anyway all the way up to if you just understood the language better you’d know why. While I agree with both of those points strongly as general principles, JavaScript also violates the principle of least surprise enough to make it concerning.

      For what it’s worth, I do like JavaScript. I really don’t think that there is any perfect programming language.

  • Lysergid@lemmy.ml
    61·
    7 months ago

    How about SQL in PostgreSql? query: select array_length(Array[]::text[], 1) Output: null

    Dont get me wrong JS is still awful

  • Juniper (she/her) 🫐@lemmy.dbzer0.com
    3·
    7 months ago

    Take an empty list and add an object to it. Get a list with an object in it.

    Take an object and add an empty list to it, that doesn’t do anything, get a zero for false?

  • Mesa@programming.dev
    2·
    7 months ago

    I’m in this no-experience-to-apprenticeship program and everyone in my class thinks type coercion is the greatest thing ever.