11–20 of 157 posts
Couple of gripes: - Still no date type - Why make it more loose? Like "Strings may be single quoted." doesn't bring any value.
‘I am “really” angry’
“I am \”really\” angry”Couple of gripes: - Still no date type - Why make it more loose? Like "Strings may be single quoted." doesn't bring any value.
Couple of gripes: - Still no date type - Why make it more loose? Like "Strings may be single quoted." doesn't bring any value.
But it's a matter of taste still and nothing that we couldn't do before. Such changes will lead to meetings where programmers discuss JSON5 quoting choices (yes, it will be a thing).
A lot of processing of these json-ld files uses normal builtins instead of special libraries eg in python doing a for line in or a stream map and the standard json lib etc.
From a glance at this spec, it seems that where an object ends is no longer something that the normal file processing most languages possess work. Which is a problem.
I’d be surprised if a extended-json ever got traction because everyone already has code that uses the lowest common denominator json parser and line splitting built into whatever language and libraries they are using and those they interchange with already use.
Having said that, the pain points I wrestle with are lack of date types and how to safely pass large integers and currencies etc. Things not addressed in the json5 spec?
Is there an official standard body behind this (and json 6 mentioned in another comment), or is it a kind of loose / informal standard left up to libraries to implement? I mean comments and trailing commas will make JSON a bit more human friendly when used in e.g. configuration (package.json), but as a pure data exchange format it doesn't add much. Mind you, there's better data exchange formats than json, like XML (y…
json-ld files (json line delimited, means one json object per line) are used extensively in data processing. A lot of processing of these json-ld files uses normal builtins instead of special libraries eg in python doing a for line in or a stream map and the standard json lib etc. From a glance at this spec, it seems that where an object ends is no longer something that the normal file processing most languages posse…
What's the point? I cringe every time a project uses both double quote and single quote, a mix of semicolon and no semicolon and a mix of tabs and space, .... Which one to pick isn't relevant as soon as the code base is consistent
> An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable.
Couple of gripes: - Still no date type - Why make it more loose? Like "Strings may be single quoted." doesn't bring any value.
What would a date type look like? An ISO-8601 string is probably as good as it'll get, else you end up with an object containing loads of additional information like timezones, offsets, etc. There's also https://json-schema.org/understanding-json-schema/reference/... for a formalized date format in JSON. The looseness seems to be aimed at human authors who want to write JSON as if it were JS, so mainly package.json.…
{
thisIsADate: new Date('1995-12-17T03:24:00Z')
}
It hasen't changed since then and it will never need to change ever in the history of mankind.
Problem solved!
Edit: Maybe this solves another problem though, but I doubt it!