Why only positive/negative infinity, but not positive/negative zero?
JSON5 was proposed long before positive/negative zero got trendy on HN
JSON5 Data Interchange Format
131–140 of 157 posts
Re: JSON5 Data Interchange Format
#132Earlier quoted context omitted.
JSON is "good enough" for a textual, mostly human readable data interchange format. But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough". For two reasons: no comments and no multiline strings. The latter might not be important for some types of configuration, but it is for things that need something like a description that is more than a single se…
> But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough". Then perhaps don't use it for a use case it was not designed to address? I understand that JSON is a very handy hammer to have, but not all things are nails.
That's kind of my point. JSON5 is a much better for configuration than JSON.
Re: JSON5 Data Interchange Format
#133"The standard has to be sufficiently simple that it makes sense to have multiple implementations." -James Clark
Re: JSON5 Data Interchange Format
#134Earlier quoted context omitted.
JSON is "good enough" for a textual, mostly human readable data interchange format. But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough". For two reasons: no comments and no multiline strings. The latter might not be important for some types of configuration, but it is for things that need something like a description that is more than a single se…
> But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough". Then perhaps don't use it for a use case it was not designed to address? I understand that JSON is a very handy hammer to have, but not all things are nails.
I mean, that’s all very well, but it’s literally one of only two formats with native support in the browser. So there’s plenty of times you don’t really have any choice other than to hammer that screw in.
Re: JSON5 Data Interchange Format
#135Re: JSON5 Data Interchange Format
#136Earlier quoted context omitted.
What's the point of standards then?
The standard says you can use either. Why do you disagree with the standard?
I disagree with the OP, not the standard. The standard says you can't use backticks for quoting strings, so it's still "up to them to decide which one you should go with".
Re: JSON5 Data Interchange Format
#137These are the monsters who told us "XML is too bloated" and "who'd ever want a self-describing, self-transformable interchange format anyway?"
The more I see things like JSONSchema and JSON5 get away from Crockford's original overly simplistic syntax, the more I think we can all agree with Richard Gabriel. Worse Is Better!
Re: JSON5 Data Interchange Format
#138Earlier quoted context omitted.
And XML is a very battle-tested alternative that supports every conceivable edge case and arbitrary depths of strictness and validation. There was soooo much energy poured in to making XML the One Format To Rule Them All. It has so many advanced features like strict definitions, includes syntax, support for mixed content, entities and references, comment syntax. But it turns out that 99% of users never needed any of…
That and any serialization format that has security implications is doomed to fail (or at least be derided).
What?!? BREH, read Effective Java on Serialization.
Every serialization format has security implications.
Some try to make this explicit and probably fail in capturing all conceivable holes. Some leave this implicit to give you "fun surprises."
Re: JSON5 Data Interchange Format
#139Earlier quoted context omitted.
Rust has similar but it scales infinitely. They're called raw strings, "normal string can contain ' " r#" raw string can contain " ' "# r###" if for some reason you need to write "# "### Kinda like heredocs
Most (newer) programming languages have a concept of multi-line string literals.
Most newer languages only have 1 variation, not infinite. Go only has backtick, python only has triple quotes. Rust has #", ##", ###", ##...#"
Re: JSON5 Data Interchange Format
#140Earlier quoted context omitted.
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.…
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.
{
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])),
}
const serialised = NuJSON.stringify(data)
const result = NuJSON.parse(serialised, allowedConstructors, fallbackConstructor)
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.