Comment by MrBuddyCasino

1 day ago

JEP 540: Simple JSON API

  > trailing commas and comments are not supported

Be strict in what you produce, be lenient in what you accept. Grr.

8 comments

MrBuddyCasino

Reply
chowells  1 day ago

Fortunately, we now have 50 years of evidence of the negative effects of this philosophy on the ecosystem. Being strict in both results in net positive effects for the entire ecosystem. Trying to be lenient in what you accept results in HTML5, where the exact parse tree for every possible input sequence is specified in order to enforce compatibility. It's no longer lenient, because that doesn't work.

  • MrBuddyCasino  1 day ago

    Apples and oranges.

    One is „accept a wide array of syntactically malformed input, ill defined, substantially complicating the parser“, the other „accept two trivial extensions to the standard that are widely used and don’t affect the resulting data in any way.“

    • dwaite  1 day ago

      So far nobody has tried to get trailing commas into the standard AFAIK.

      Comments were explicitly disallowed from JSON since the beginning, because they could be used as a side-channel for vendor-specific extension mechanisms and harm interoperability.

    • dwohnitmok  1 day ago

      > accept two trivial extensions to the standard that are widely used and don’t affect the resulting data in any way

      That's always how it starts. If they're truly trivial the reasoning also cuts the other way. Remove them upstream.

mpyne  1 day ago

From the JEP's goals: "Provide only those data types and operations required for strict conformance to RFC 8259, in order to facilitate machine-to-machine communication."

In that case they made the right choice, as machines won't be inserting trailing commas or comments in the first place, and the risk of having consuming apps inadvertently accept invalid data would be high otherwise.

pixl97  1 day ago

This is a great way to ensure you have good application interoperability, but really starts going down hill when you're talking about security and consistency.

  • mpyne  12 hours ago

    From the perspective of the one and only app you care about it may improve operability of that app with others.

    But from the perspective of a potentially distributed ecosystem of apps and libraries as employed in practice in modern systems, it's actually harmful to interoperability.

    Other libs/services/apps that touch the malformed JSON that this change would accept might be present in the overall system and crash on that data. The risk grows with the more components of the overall system that silently accept malformed data and allow the bad data to make its way deeper before it causes issues.

    This is what “fail fast” was meant for, if something is going to cause problems in your system at some point in the future, make that “some point” happen ASAP, so that it is easier to identify and fix the source of the flaw.