Meme transcription: Panel 1. Two images of JSON, one is the empty object, one is an object in which the key name maps to the value null. Caption: “Corporate needs you to find the difference between this picture and this picture”

Panel 2. The Java backend dev answers, “They’re the same picture.”

  • AggressivelyPassive@feddit.de
    link
    fedilink
    arrow-up
    2
    arrow-down
    2
    ·
    4 months ago

    That’s exactly not the thing, because nobody broke the contract, they simply interpret it differently in details.

    Having a null reference is perfectly valid json, as long as it’s not explicitly prohibited. Null just says “nothing in here” and that’s exactly what an omission also communicates.

    The difference is just whether you treat implicit and explicit non-existence differently. And neither interpretation is wrong per contract.

    • MostlyBlindGamer@rblind.com
      link
      fedilink
      English
      arrow-up
      8
      ·
      4 months ago

      I think we’re fully in agreement here: if the API doesn’t specify how to handle null values, that omission means they’re perfectly valid and expected.

      Imagine a delivery company’s van exploding if somebody attempts to ship an empty box. That would be a very poorly built van.

    • masterspace@lemmy.ca
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      2
      ·
      4 months ago

      Null means I’m telling you it’s null.

      Omission means it’s not there and I’m not telling you anything about it.

      There is a world of difference between those two statements. It’s the difference between telling someone you’re single or just sitting there and saying nothing.

      • JackbyDev@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 months ago

        I (think, at least) the point they’re making is that unless the API contract specifically differentiates between “present and null” and “absent” then there is no difference. (Specifically for field values.)

        • masterspace@lemmy.ca
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          4 months ago

          The point I’m making is kind of the opposite, unless the contract explicitly states that they’re the same they should not be treated as the same, because at a fundamental level they are not the same thing even if Java wants to treat them as such.

      • AggressivelyPassive@feddit.de
        link
        fedilink
        arrow-up
        1
        arrow-down
        3
        ·
        4 months ago

        Nope.

        If there’s a clear definition that there can be something, implicit and explicit omission are equivalent. And that’s exactly the case we’re talking about here.

        • masterspace@lemmy.ca
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          2
          ·
          edit-2
          4 months ago

          Sure, in a specific scenario where you decide they’re equivalent they are, congratulations. They’re not generally.

          • AggressivelyPassive@feddit.de
            link
            fedilink
            arrow-up
            2
            arrow-down
            2
            ·
            4 months ago

            Did you read the comments above?

            You can’t just ignore context and proclaim some universal truth, which just happens to be your opinion.

            • Doc Avid Mornington@midwest.social
              link
              fedilink
              English
              arrow-up
              4
              arrow-down
              3
              ·
              4 months ago

              At the (SQL) database level, if you are using null in any sane way, it means “this value exists but is unknown”. Conflating that with “this value does not exist” is very dangerous. JavaScript, the closest thing there is to a reference implementation for json serialization, drops attributes set to undefined, but preserves null. You seem to be insisting that null only means “explicit omission”, but that isn’t the case. Null means a variety of subtly different things in different contexts. It’s perfectly fine to explicitly define null and missing as equivalent in any given protocol, but assuming it is not.

              • AggressivelyPassive@feddit.de
                link
                fedilink
                arrow-up
                2
                arrow-down
                1
                ·
                4 months ago

                Again, did you actually read the comments?

                Is SQL an API contract using JSON? I hardly think so.

                Java does not distinguish between null and non-existence within an API contract. Neither does Python. JS is the weird one here for having two different identifiers.

                Why are you so hellbent on proving something universal that doesn’t apply for the case specified above? Seriously, you’re the “well, ackshually” meme in person. You are unable or unwilling to distinguish between abstract and concrete. And that makes you pretty bad engineers.

                • Doc Avid Mornington@midwest.social
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  arrow-down
                  2
                  ·
                  4 months ago

                  If your SQL model has nulls, and you don’t have some clear way to conserve them throughout the data chain, including to the json schema in your API contract, you have a bug. That way to preserve them doesn’t have to be keeping nulls distinct from missing values in the json schema, but it’s certainly the most straightforward way.

                  The world has more than three languages, and the way Java and Python do things is not universally correct. I’m not up to date on either of them, but I’m also guessing that they both have multiple libraries for (de) serialization and for API contract validation, so I am not really convinced your claims are universal even within those languages.

                  I am not the other person you were talking to, I’ve only made one comment on this, so not really “hellbent”, friend.

                  Yes, I am pretty sure I read the comments, although you’re making me wonder if I’m missing one. What specific comment, what “case specified above” are you referring to? As far as I can see, you are the one trying to say that if a distinction between null and a non-existent attribute is not specified, it should universally be assumed to be meaningless and fine to drop null values. I don’t see any context that changes that. If you can point it out, specifically, I’ll be glad to reassess.

              • Saizaku@lemmy.dbzer0.com
                link
                fedilink
                arrow-up
                1
                ·
                4 months ago

                At the (SQL) database level, if you are using null in any sane way, it means “this value exists but is unknown”.

                Null at the SQL means that the value isn’t there, idk where you’re getting that from. SQL doesn’t have anything like JS’s undefined, there’s no other way to represent a missing value in sql other than null (you could technically decide on certain values for certain types, like an empty string, but that’s not something SQL defines).