Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON with Commas and Comments

nigeltao.github.io

Post reply on HN
Print view View original

231–240 of 251 posts

Re: JSON with Commas and Comments

#231

Post by lloeki »

nly wrote: post #189
lloeki wrote: post #159

Earlier quoted context omitted.

I benefit greatly from schema validation in Ruby, ensuring that ingress-processing code does not receive e.g a String or Hash instead of an Array which would have things blow up way after the ingress edge when a call to an Array method fails, or worse, produce silently broken behaviour that may or may not blow up even farther down the road because both String and Hash respond to e.g #[](Integer).

Yeah but Ruby is a dynamically typed language. There's not much benefit to codegen since nothing is checked at compile time anyway.

I found code generation to be useful in Ruby with protobuf. This:

https://github.com/lloeki/ruby-skyjam/blob/master/defs/skyja...

gives that:

https://github.com/lloeki/ruby-skyjam/blob/master/lib/skyjam...

I would certainly enjoy having a DSL to write descriptive code to validate using JSON schema, but it would be even better if the Ruby definitions could be generated and persisted in Ruby files using that DSL.

Also, storing things in basic hash/array types works, but having dedicated types is useful, so that one can ensure not shoving one kind of hash in place of another unrelated kind of hash.

As for types themselves in general, there's RBS and Sorbet. One could have type definition generation as well for even deeper static and runtime checks.

Re: JSON with Commas and Comments

#232

Post by majkinetor »

q3k wrote: post #175
secondcoming wrote: post #158

Earlier quoted context omitted.

Json does have schemas

The JSON schema ecosystem is a mess. json-schema.org is one thing, openapi is another (it uses an 'extended subset' of json-schema.org, which is another way of saying 'incompatible'), there’s also typeschema, and a bunch of other pet projects. There is no official JSON schema RFC, there is no official linking between json-schema.org and the JSON RFC. There is no push to make every language that supports JSON to also…

XML schema is joy ?

Re: JSON with Commas and Comments

#233

Post by majkinetor »

_0w8t wrote: post #149

For comments in plain JSON a common approach is to use keys like "comments" or "description" in object literals. As for trailing comma the only real issue in practice is noisy unified diff output. But for JSON word diff or similar works better in any case when the trailing comma is not an issue.

That is not only issue in practice. I can't count the number of times when somebody changed the json adding single line thinking what could go wrong without test...

Re: JSON with Commas and Comments

#234

Post by sneak »

arcatek wrote: post #153
sneak wrote: post #119

Earlier quoted context omitted.

Comments were intentionally excluded from JSON, lest they be used to instruct the parser and cause fragmentation of the ecosystem.

I know it's the official reason, but it's also a really bad one - nothing prevents current JSON parsers to add some weird syntactic rules inside plain strings (similar to "use strict" in JS), but you don't see that happen. It's always been a completely hypothetical issue. The only real reason why comments would be problematic is that they are a pain to preserve in a consistent way when editing a file, and thus would…

I agree that it was stupid. I am 100% pro-comment.

Re: JSON with Commas and Comments

#235

Post by qbasic_forever »

Ballas wrote: post #91
qbasic_forever wrote: post #76

Alternatively, just use JSON as a low-level data interchange much like a CSV file. Put all your human-managed content in a configuration language that emits JSON, like jsonnet, cue, dahl, etc. These languages add comments, function, variables, and much, much more (like fancy data cascades, validation, schemas, imports, etc.) to make managing configuration at scale easy.

Why even go to the trouble of converting it to json then?

It simplifies your code that depends on configuration. Instead of having to parse the config language you just read the JSON. Pretty much every programming langauge has a JSON parser built in to its standard library, while support for higher level config langauges is a lot less ubiquitous.

It also makes it easier for other tools to generate, validate, or output config that feeds into your system. They can do whatever processing they want and emit plain old JSON.

Re: JSON with Commas and Comments

#236

Post by marcosdumay »

zeroimpl wrote: post #10

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

While we are at it, how about making the parsers accept non-ascii space, so that things don't break if somebody using Windows edit a file somewhere and adds a BOM.

Re: JSON with Commas and Comments

#237

Post by oblio »

aaron-santos wrote: post #5
Supermancho wrote: post #4

Earlier quoted context omitted.

> a practice which would have destroyed interoperability A baseless reason is not a compelling reason. Some imagined eventual use is not relevant to the utility and convenience. Interoperability (in this greater undefined sense posited) cannot be maintained via syntax anyway. > stripping comments before handing off the a JSON parser. Putting an extra processing step before use of JSON is impractical.

The base is the part right before that. > I removed comments from JSON because I saw people were using them to hold parsing directives > Putting an extra processing step before use of JSON is impractical. Care to explain?

Simple example. JSON is frequently used for configuration files. Comments break syntax highlighting for JSON.

Similar thing if you want to inspect a JSON dump into a file.

Re: JSON with Commas and Comments

#238

Post by lostmsu »

kergonath wrote: post #148
_ZeD_ wrote: post #94

Earlier quoted context omitted.

Problem is... YAML sucks, as human readable format

YAML is fine as a user. It can be just JSON without some of its visual clutter if you like brackets, or much more concise if you prefer. All the complexity related to anchors and such is unfortunate, but that’s a problem for parser writers.

> YAML is fine as a user

The link in the main article convinced me otherwise: https://noyaml.com/

Re: JSON with Commas and Comments

#239

Post by Lazare »

jtdev wrote: post #215
Lazare wrote: post #130

Earlier quoted context omitted.

And I suppose the vast amounts of XML (still!) flowing across the internet show there's no need for JSON at all , so the real mistake was even inventing JSON? (Also, as gets pointed out every time this topic pops up on HN, including multiple times on the submission already, the main demand isn't people wanting to add comments to the JS flowing across the wire, but to config files sitting on disk. Responding to people…

Crockford (and many others) found that the many flaws inherent to XML warranted a new specification, so JSON was born. If you have an issue with JSON, go create your own spec, don’t shit all over the perfectly capable, simple, elegant specification that is JSON.

> If you have an issue with JSON, go create your own spec

And many people have. You're literally posting this in response to someone submitting the new spec they created to solve this.

I don't understand what you're trying to argue here.

Re: JSON with Commas and Comments

#240

Post by CuriousSkeptic »

q3k wrote: post #219
johannes1234321 wrote: post #216

Earlier quoted context omitted.

I agree that as a standard it isn't great. However the fact that it is so successful shows that the minimalistic design has benefits for adoption. And regarding integer ranges: Any user has restrictions on top of the generic format. Some fields have to be present for the application to work, some fields have to be a string, others an array. Some integer has to be between 0 and 100, some array has to have 5 elements.…

> Any user has restrictions on top of the generic format. The problem is that you are not guaranteed to know, as a JSON library user, that the library has not mangled the numbers it received on the wire prior to your application receiving it - so you don't know if you having .a set to 42 is the result of 42 being sent over the wire, or an implementation dropping bits that are outside the range of you library's suppor…

> the receiving side silently casted to 32-bit floats, losing data (as the RFC permits)

Had to look that up. Was under the impression the rfc only specified the syntax. But here it is

> This specification allows implementations to set limits on the range and precision of numbers accepted.

I don’t think the implication is that it must be done by silently loosing precision though. A loud error would fit that description just fine. So in this case I would blame the implementation not the spec.

Post reply on HN