Been there, done that: https://github.com/nanoscopic/ujsonin
"JSON" parser in both C, Perl, and Golang. All three support "JSON" with or without commas as you desire and comments.
JSON with Commas and Comments
101–110 of 251 posts
Re: JSON with Commas and Comments
#102Earlier quoted context omitted.
Truly representing dates would make the semantics more complicated than JSON, Javascript, CSS, and C++20 combined. The practical approaches are to represent it as time since the Epoch (in floating point) or a string where both sides somehow agree what "03/04/05" means.
I'd recommend always representing dates or datetimes as a string in ISO-8601 format.
Which ISO-8601 format though? There are a variety to choose from. You want the date-only format? or the date+time format? you want the T separator or space? Is time zone represented?
All these are allowed according to the ISO standard.
Re: JSON with Commas and Comments
#103Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag. As a case in point, th…
> Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. I think the most correct way to deal with this problem is to get IETF and ECMA to update the JSON standard first. Honestly, comma-after-final-element and comments…
I think that json is mostly a lightweight, human-readable data exchange format for machines to communicate. It's generally not meant to be written by humans.
Re: JSON with Commas and Comments
#104Earlier quoted context omitted.
> Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. I think the most correct way to deal with this problem is to get IETF and ECMA to update the JSON standard first. Honestly, comma-after-final-element and comments…
I think that json is mostly a lightweight, human-readable data exchange format for machines to communicate. It's generally not meant to be written by humans.
There are already better formats if we just want machines to communicate though; e.g. protobuf, msgpack.
The whole reason JSON is text-based is to make it human-readable while also enabling data exchange, but the lack of comments works against that goal.
Re: JSON with Commas and Comments
#105Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag. As a case in point, th…
> Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. I think the most correct way to deal with this problem is to get IETF and ECMA to update the JSON standard first. Honestly, comma-after-final-element and comments…
>I never understood why they weren't part of the original spec
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
>Trailing commas in objects were only introduced in ECMAScript 5. As JSON is based on JavaScript's syntax prior to ES5, trailing commas are not allowed in JSON.
json was largely `eval`d when it first hit the scene. It was easy to parse because you just received it and `eval`d it directly to parse. worked in every browser. security concerns over time lead to this being rightfully replaced with the JSON object and its associated encoder and decoder.
however, since early javascript didn't allow for trailing commas, neither could JSON if it wanted to be able to be `eval`d.
Re: JSON with Commas and Comments
#106Earlier quoted context omitted.
ISO-8601 not good enough for you? It’s a standard, human readable, has every datetime detail, every language that supports JSON can read it. What’s missing?
I've never had a problem with dates by always serializing them as ISO-8601. It absolutely has every benefit you cite. It's the only ISO spec I know the name of without having to look it up.
Is the -0700 offset PDT or MST? ISO-8601 doesn’t solve a whole bunch of problems related to locale-aware date math.
Re: JSON with Commas and Comments
#107Earlier quoted context omitted.
There’s no concept of mutability in JSON. A JSON parser could give you immutable arrays and maps if it wanted to.
Yes, but json by itself doesn't actually do anything. It'd always be used in context of javascript/python/ etc.. As I said you could interpret it as a tuple or I guess a frozen array for javascript? I don't think there is a native immmutable array in javascript. If it's a map I'm a bit more unsure how you'd check to find the object (quickly). You're basically getting into the how to store a struct/class as a map key.…
> I don't think there is a native immmutable array in javascript.
I'm here to tell you that `Object.freeze()` works just fine on arrays.
Re: JSON with Commas and Comments
#108Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag. As a case in point, th…
Or just do RSON? https://github.com/rson-rs/rson
I honestly don't want to bash JS, but typing is not it's strength.
(Not affiliated)
Re: JSON with Commas and Comments
#109Earlier quoted context omitted.
> I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together. As recently as 2017, the Google Translate API used to return completely invalid JSON with empty array indices instead of nulls ([,,,] instead of [null,null,null,null]). This broke several JSON parsers until they patched around Google's cavalier abuse of the language. Your experience of everyth…
That sounds more like a bug that, because the group responsible for the bug didn’t fix the bug and was extremely important to the community, developers of JSON parsers had to put in bug fixes on their end instead. I’m not familiar with the details of that event, but it doesn’t sound like anyone was actually accepting this as a new valid variant JSON, and AFAIK it didn’t lead to the propagation of different variants o…
> I’m not familiar with the details of that event, but it doesn’t sound like anyone was actually accepting this as a new valid variant JSON
When they accept it, it becomes defacto valid. That's how acceptance works.
See also http://seriot.ch/parsing_json.php#41 for a big table of "JSON-encoded data and JSON parser that didn’t work perfectly together". Read the whole page though. It's quite enlightening.
Re: JSON with Commas and Comments
#110Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag. As a case in point, th…
Or just do RSON? https://github.com/rson-rs/rson I honestly don't want to bash JS, but typing is not it's strength. (Not affiliated)
I think that's the opposite of what GP is advocating; they're arguing that a better approach than defining entire new formats, we should just augment existing JSON implementations. I'd guess that the rationale is that it would be a tougher uphill battle to get people to switch to an entirely new format, but adding new features to implementations they're already using wouldn't require making anyone switch.