[avolcano]

Trusting the community to do the right thing is better than handicapping your users.

Regardless, of course, people add metadata to JSON already - there's zero reason you can't "_type": "int". It's a completely arbitrary reason.

[IanCal]

> Regardless, of course, people add metadata to JSON already - there's zero reason you can't "_type": "int"

Which is fine, because it's in a format that everyone can parse. Adding

    //COMMAND: Extension(github:IanCal/preparser).parsethis

is the kind of things this forbids. Most peoples parsers would ignore this as a comment (if we have comments), but maybe some would do it in a special way. Either everyone ignores the comments in the parser (this is unlikely to carry on for long, someone will want to extend it) or nobody is allowed comments. That way everyone parses the same text.

[jerf]

"Trusting the community to do the right thing is better than handicapping your users."

And the "community" in question had repeatedly and grossly demonstrated itself to be unworthy of such trust.

Crockford was not hypothesizing that this might happen, he'd seen it. Repeatedly. If you want to argue against it even so, fine, but bear in mind that is what you are arguing against, real pain that real people experienced, not mere possibilities.

[wvenable]

JSON did support comments for a time and people were starting to use it for meta data.

The problem is that JSON is not meant to be used a configuration file format and just because it's really good for information exchange, doesn't mean it's good for configuration (and vice-versa). Configuration really requires comment support and information-exchange is better avoiding it. Two standards are needed.

[phpnode]

right - but that is valid syntax! any json parser can understand that, and that's what he recommends doing instead. But if you're doing this in comments, you end up writing your own mini language to describe your annotations, and nothing else knows how to parse it. that should clearly be avoided.

[esailija]

If JSON had comments, then of course any JSON parser could understand those comments just as well as they can currently understand "_type": "int". What am I missing?

[masklinn]

That because they're comments specific JSON parsers could (and likely would) interpret processing instructions embedded in those comment to toggle behaviors on the fly. Crockford's fear (founded I think) was that comments would be used to "extend" json.

[esailija]

Yes I get that. What I don't get is how "_processing_instruction": "whatever" is any different.

[phpnode]

when you do

    {
        "_type": "int",
        "foo": "123"
    }

a JSON parser will always know how to represent that object. How you process that object is up to you.

However, when you write:

    {
        // @type int this is a comment
        "foo": "123"
    }

and you call JSON.parse(), what would you expect to get back? You can no longer represent it as a simple object, you need some way to access the comment, how do you do that? Moreover, whose responsibility is it to process the annotation in that comment? the parser's? Should you get back an integer rather than a string for obj.foo? how would you support different types of annotation? What happens if you're using parser A and your client uses parser B? Does parser B support all the annotations that parser A supports? If you need to modify a JSON structure, e.g. JSON decoding, adding a property and re-encoding, should the comments be preserved? ...

You can see that having comments introduces a whole host of other questions, ambiguity and would only make it harder for different platforms to share data. Avoiding this kind of cruft is why JSON is winning vs XML for most things these days.

[esailija]

In the eyes of compliant parser (assuming JSON supported comments) it is just a comment like "_type": "int" is just a key-value pair.

However, when using ad hoc parser, then all bets are off what the result is in both cases again, not just the comment case. Regardless of comment support in JSON the same problem appears to exist.