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. But, json is not ideal for configuration for multiple reasons.
If you wanted JSON to parse into actual date objects, you could always do:
{
thisIsADate: new Date('1995-12-17T03:24:00Z')
}
It would be simple enough for parsers in other languages to parse this into their own date objects. Much simpler than using regexs to find ISO strings.
I think allowing a whitelisted set of constructors (so it's extensible, but with some standard ones) as types in a future JSON-like could be good. e.g.
const serialised = NuJSON.stringify(data)
const result = NuJSON.parse(serialised, allowedConstructors, fallbackConstructor)
And if allowedConstructors wasn't present, it'd default to including all the standard JS ones (Map,Set,Date,Symbol,ArrayBuffer etc). The fallback constructor would be used if there were data types in the data that didn't have matching allowed constructors. By default it would through an error.
Of course, my ideal NuJSON would also include bigints, multiline strings, comments, bare keys (i.e. without having to wrap them in quotes).
Stretch nuJSON would also include the ability to serialise circular graph structures, perhaps through the use of a Reference([up, up, "aSymbol"]) data type.
I know this is how Javascript is done nowadays but using constructors for maps and arrays just seems like unnecessary syntax to me. And if you're going to initialize an array buffer too, you might as well just not use JSON at all and send plain Javascript code over the wire.
I think all JSON needs in this regard is type hinting. Let everything else be handled by the application:
{
birthdayParty: Date 1632817436514,
sounds: String? { // zomgwtfbbq comments too
cow:"moo",
fox: null
},
possibilities: ["she loves me", "she loves me not", 42],
aSymbol: Symbol "tag",
aBuffer: Uint8 [104, 101, 108, 108, 111]
}
I think the main difference between my suggestion and yours is that mine has more brackets. I think type hinting and 'constructors' are basically the same thing, but I like the types to be extensible, so even in your version, I'd make the type hints things that could be provided into the NuJSON.parse function.
Obviously, in your version my approach would be
sounds: Map {
cow: "moo",
fox: null
},
possibilities: Set ["she loves me", "she loves me not", 42]
I suppose that the idea could be that type hints are entirely ignoreable, and if you strip them the file just becomes normal JSON?
I suppose my point was that you don't have to specify types for maps and sets at all (which I didn't do in my example,) the existing syntax already does that. [] is already a set, {} is already a map. Type hints would just be used for the values.
Sending type definitions seems like a good idea. Although at that point it might as well not even be called any kind of JSON.
Useful when you need to input already double-quoted 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).
It brings it closer to JavaScript behavior I guess.
I guess it's nice to have ability to copy random js object declaration to actual json without editing
You wouldn't say that mammals write C all the time, would you? Front end development would be so much better if you could just spew json at people in a table.
>You wouldn't say that mammals write C all the time, would you?
Yes. Mammals do write C all the time, because humans are mammals. And C is meant to be human readable and writable.
> Front end development would be so much better if you could just spew json at people in a table.
That's literally what a JSON API is, and there are tons of them. And for each of them, a human had to be able to read and comprehend JSON responses and write JSON requests in code. There's a reason JSON is pretty-printed in the debug consoles of browsers.
To say nothing of all of the package definitions or framework configs that are written (by hand) in JSON.
The fact that most JSON is machine generated at present has nothing to do with its original design intent. Most Javascript, CSS and HTML are machine generated nowadays as well, but they were meant to be written by a person using a text editor.
I've worked on 4+ years of technology that was entirely based on humans hand-tweaking, editing, and updating JSON configs. My text editors validate it quickly, and know how to fold, sort, prettify. Based on my experience (and editing it all day long) It's a very human readable and editable configuration.
The looseness seems to be aimed at human authors who want to write JSON as if it were JS, so mainly package.json. But, json is not ideal for configuration for multiple reasons.