4 ms·

Couple of gripes: - Still no date type - Why make it more loose? Like "Strings may be single quoted." doesn't bring any value.

AlfeG 5y ago
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
Cthulhu_ 5y ago
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/string.html#dates-and-times 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.
- rbut 5y ago
  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.
  - kybernetikos 5y ago
    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. { birthdayParty: Date(1632817436514), sounds: Map([["cow", "moo"], ["fox", "?"]]), possibilities: Set(["she loves me", "she loves me not"]), aSymbol: Symbol("tag"), aBuffer: UInt8Array(ArrayBuffer([104, 101, 108, 108, 111])), } So you'd do something like 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.
    - krapp 5y ago
      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] }
      - kybernetikos 5y ago
        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?
        krapp 5y ago
        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.
        kybernetikos 5y ago
        I don't agree that you don't have to specify types for maps and sets. For example {true: "yes", false: "no"} Is not valid JSON, but Map [[true, "yes"], [false, "no"]] should be valid 'NuJSON'. Maps and Sets are semantically different to Objects and Arrays, and they are Javascript standard objects that should ideally be supported by the default serialisation. The other alternative of course is to force the deserialisation code to fix them up afterwards, but that is painful. I want to be able to stringify records with Sets, Maps, Arrays and Objects in, and have that work, even if they have behavior not supported by objects and arrays, and I don't think the user should have to fix up the output after parsing of JSON containing standard javascript objects.
alpaca128 5y ago
I agree about the single quotes, but many use single quotes for strings in JS and so it's understandable to have this consistent.
rbut 5y ago
Because: ‘I am “really” angry’ Is much nicer than: “I am \”really\” angry”
- peoplefromibiza 5y ago
  and now you have two problems is this any better? 'I\'m "really" angry, don\'t do it again!' in many languages single quotes are used as apostrophes and are very very common, much more common than double quotes.
  - kangalioo 5y ago
    Nobody's forcing you to use single quotes as delimiters. "I'm \"really\" angry, don't do it again!"
- eptcyka 5y ago
  Json is not meant to be human readable or writeable.
  - SigmundA 5y ago
    Second sentence from json.org: "It is easy for humans to read and write."
  - jenscow 5y ago
    But JSON5 is.
  - krapp 5y ago
    All text based data formats are meant to be human readable and human writable, and humans read and write JSON all the time.
    - eptcyka 5y ago
      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.
The_Colonel 5y ago
Single quote strings are useful when the string contains many double quotes (e.g. XML with attributes).
pawelduda 5y ago
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).

AlfeG 5y ago

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

Cthulhu_ 5y ago

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/string.html#dates-and-times 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.

rbut 5y ago
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.
- kybernetikos 5y ago
  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. { birthdayParty: Date(1632817436514), sounds: Map([["cow", "moo"], ["fox", "?"]]), possibilities: Set(["she loves me", "she loves me not"]), aSymbol: Symbol("tag"), aBuffer: UInt8Array(ArrayBuffer([104, 101, 108, 108, 111])), } So you'd do something like 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.
  - krapp 5y ago
    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] }
    - kybernetikos 5y ago
      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?
      - krapp 5y ago
        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.
        kybernetikos 5y ago
        I don't agree that you don't have to specify types for maps and sets. For example {true: "yes", false: "no"} Is not valid JSON, but Map [[true, "yes"], [false, "no"]] should be valid 'NuJSON'. Maps and Sets are semantically different to Objects and Arrays, and they are Javascript standard objects that should ideally be supported by the default serialisation. The other alternative of course is to force the deserialisation code to fix them up afterwards, but that is painful. I want to be able to stringify records with Sets, Maps, Arrays and Objects in, and have that work, even if they have behavior not supported by objects and arrays, and I don't think the user should have to fix up the output after parsing of JSON containing standard javascript objects.

alpaca128 5y ago

I agree about the single quotes, but many use single quotes for strings in JS and so it's understandable to have this consistent.

rbut 5y ago

Because: ‘I am “really” angry’ Is much nicer than: “I am \”really\” angry”

peoplefromibiza 5y ago
and now you have two problems is this any better? 'I\'m "really" angry, don\'t do it again!' in many languages single quotes are used as apostrophes and are very very common, much more common than double quotes.
- kangalioo 5y ago
  Nobody's forcing you to use single quotes as delimiters. "I'm \"really\" angry, don't do it again!"
eptcyka 5y ago
Json is not meant to be human readable or writeable.
- SigmundA 5y ago
  Second sentence from json.org: "It is easy for humans to read and write."
- jenscow 5y ago
  But JSON5 is.
- krapp 5y ago
  All text based data formats are meant to be human readable and human writable, and humans read and write JSON all the time.
  - eptcyka 5y ago
    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.

The_Colonel 5y ago

Single quote strings are useful when the string contains many double quotes (e.g. XML with attributes).

pawelduda 5y ago

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).