this post was submitted on 15 Sep 2024
2 points (100.0% liked)

Programming

17424 readers
60 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
top 7 comments
sorted by: hot top controversial new old
[–] scarecrw@lemmy.one 1 points 2 months ago* (last edited 2 months ago)

Why restrict to 54-bit signed integers? Is there some common language I'm not thinking of that has this as its limit?

Edit: Found it myself, it's the range where you can store an integer in a double precision float without error. I suppose that makes sense for maximum compatibility, but feels gross if we're already identifying value types. I don't come from a web-dev/js background, though, so maybe it makes more sense there.

[–] masterspace@lemmy.ca 1 points 2 months ago* (last edited 2 months ago) (1 children)

A summary:

An old proposal (2015, not sure why OP posted it now), that basically proposes to put some more standards and limitations around JSON formatting to make it more predictable. Most of it seems pretty reasonable:

  • Must be UTF-8 encoded and properly escape Unicode characters
  • Numbers must respect the JavaScript number Type and it's limitations (i.e. max magnitude of an int etc.)
  • Objects can't have duplicate keys
  • The order of keys in objects does not matter
  • A JSON file does not need to have a top level object or array, it can be any JSON value (i.e. just a string or a number is still valid JSON).
  • It proposes that when processing JSON, any unrecognized keys should be ignored rather than errored

It recommends:

  • Specific formats for date-time data
  • That binary data be stored as a bas64url string

Honestly, the only part of this I dislike is the order of keys not mattering. I get that in a bunch of languages they use dictionary objects that don't preserve order, but backend languages have a lot more headroom to adapt and create objects that can, vs making a JavaScript thread loop over an object an extra time to reorder it every time it receives data.

[–] GTG3000@programming.dev 0 points 2 months ago (1 children)

Personally, I prefer duplicate keys to be eaten by the parser but I can see how it'd be beneficial to prevent them.

[–] masterspace@lemmy.ca 1 points 2 months ago* (last edited 2 months ago)

I'm honestly unsure if they intend the 'must-ignore' policy to mean to eat duplicate keys without erroring, or just to eat keys that are unexpected based on some contract or schema....

[–] grrgyle@slrpnk.net 0 points 2 months ago (1 children)

Just skimmed but seems like a decent idea. Not that I've knowingly run into issues parsing JSON too much

[–] towerful@programming.dev 0 points 2 months ago (1 children)

It's from 2015, so its probably what you are doing anyway

[–] lysdexic@programming.dev 1 points 2 months ago* (last edited 2 months ago)

It’s from 2015, so its probably what you are doing anyway

No, you are probably not using this at all. The problem with JSON is that this details are all handled in an implementation-defined way, and most implementation just fail/round silently.

Just give it a try and send down the wire a JSON with, say, a huge integer, and see if that triggers a parsing error. For starters, in .NET both Newtonsoft and System.Text.Json set a limit of 64 bits.

https://learn.microsoft.com/en-us/dotnet/api/system.text.json.jsonserializeroptions.maxdepth