Newtonsoft.json: Json5 and comments

[XeonG]

Would be nice if there was a way to add comments to fields that also appear in the json file.. like

[RangeAttribute(0.01f, 50f), JsonComment("Blah Description (Range 0.01f, 50f)")]
public float GrowIncrement = 0.42f;

You can currently do some sort of dumb crap like JsonProperty("GrowIncrementPerSecond (Range 0.01f, 50f)")]
but its just ugly to see in json file not to mention.... when a comment line above it would be better as description.

So it would be nice if it were possible for the serialized json to get the included comment, so its easier to know more about the property does (like by a third party) if it was game config file!

[markusschaber]

Just as a side note: JSON does not officially support comments according to the JSON standard.

[XeonG]

Well it's a dumb basic standard then...https://www.reddit.com/r/programming/comments/4v6chu/why_json_doesnt_support_comments_douglas_crockford/

JSON5 now has inline comments and is thus a far better standard going forward that just needs more support and would be nice if newton supported it.

To finally have configurations in json format with actual comments written inline next to some properties etc is far more useful, than forcing them to go find some extra help file documentation that would give some more insight into things. Just makes things a lot easier.

[XeonG]

https://stackoverflow.com/questions/9495718/how-do-i-add-comments-to-json-net-output

...I'm not the only one would wanted this and the accompanying JsonComment attribute added for more convenience to have these comment descriptions added into the serialized file... would be very useful.

[nikeee]

VSCode, TypeScript and other popular programs allow comments in their JSON config files. It's pretty common for JSON configs to contain comments now.

It would be nice if we had this feature, so we could just serialize a default config for the user. Ignoring comments while deserializing was implemented a long time ago. So it's just the part the can write comments that is missing.

[nikeee]

I opened a similar issue for the new System.Text.Json api here:
https://github.com/dotnet/runtime/issues/35251

[FyiurAmron]

If you add comments this way, it's no longer JSON, and thus doesn't have to be neither understood nor parsed nor serialized/deserialized by conforming parsers. If you want to use jsonc, use a jsonc parser. See https://stackoverflow.com/questions/244777/can-comments-be-used-in-json , https://nlohmann.github.io/json/features/comments/ etc. for in-depth discussion.

[nikeee]

Comments in JSON are pretty standard for configuration files (not data transfer, of course). This is why this JSON-Library supports comments.
No need to spam downvotes because of this.

[FyiurAmron]

@nikeee you don't understand. Those configuration files ain't JSON. Simple as that. At least read the stuff I linked before spreading bullshit around.

Stupidity & nonsense is a completely valid reason for downvotes.

[nikeee]

Those configuration file ain't JSON.

As I already said in the other issue, this is correct. But that doesn't stop us from doing it anyways, because Json.NET as well as System.Text.Json already support non-standard comments. It's not about reading comments, which is the reason that Crockford stripped comments from JSON. It's about writing them if the user wants it. They are already ignored when reading, if the parser is configured that way.
If it doesn't fit in the API scope (which I'd understand), we can at least think of providing an API so that a 3rd party library can implement this without implementing a JSON parser for themself.

That will be my last comment answering you. You are just too mean without any reason.

[FyiurAmron]

@nikeee

Json.NET as well as System.Text.Json already support non-standard comments

No. They are not "supported" - if they were, you wouldn't be able to create an issue/PR requesting supporting them. They are allowed to be ignored, mostly because many inane people are using them even if it's wrong for a multitude of reasons, and it's the burden of a lib this big to support all the edge cases required for normal use, especially in consumer context. It by itself by no means mean "supporting" something.

Putting aside the fact that Json.NET is now mostly in maintenance mode (due to System.Text.Json), bloating it with another obscure extension wouldn't be a good idea anyway. Taking that into account, it's outright absurd. There are tons of actual bugs and problems that should be fixed here first; implementing something like this is too easily possible without trying yet again to blend the difference between JSON and JSON-like schemas.

They are already ignored when reading

Yes, because a lax parser should, if possible, ignore well-known standard deviations or broken markup on input (see e.g. HTML parsers). That's completely rational. It goes with the rule "accept as much as possible and as lax as possible, emit as little as possible and as strict as possible".

we can at least think of providing an API so that a 3rd party library can implement this without implementing a JSON parser for themself.

Who's the "we" here? This is an issue tracker for Json.NET. What you propose (_a 3rd party library can implement this without implementing a JSON parser for themself_) is not even a real feature request - it's a proposal for creating a jsonc parser or implementing it as a Json.NET extension. If so, find some nice internet forum and discuss it there, instead of spamming. Alternatively - write the code by yourself, and link your fork/repo here. I think nobody would mind that (I, e.g., wouldn't). Don't expect it to be merged, and don't expect a standing ovation, though.

FWIW, implementing it ATM is trivial, I'm wondering why you haven't done it yourself; it shouldn't take much more time than you already wasted commenting on issue trackers about it. You can also just use something like https://github.com/json5/json5-dotnet or similar, or just use YAML, https://github.com/aaubry/YamlDotNet - JSON is a valid YAML subset, so you should be easily able to parse & load your jsonc or whatever with it.

As an aside: the fact you don't see the reason for my implied "meanness" conveys much about your intelligence in this context. I prefer to be "mean", than to be dumb. The former is mostly a matter of opinion, the latter ain't.

[nikeee]

Alternatively - write the code by yourself, and link your fork/repo here.

I did here and I explicitly ask for feedback/opinion and whether this is a feature to consider. It is also linked above, as I referenced this issue. By seeing your downvote, you already seem to know that this PR exists, so your comment is kinda pointless.

I think nobody would mind that (I, e.g., wouldn't). Don't expect it to be merged, and don't expect a standing ovation, though.

I don't expect that. But most of the stuff required to implement this would require opening up some internal APIs. Otherwise, the only solution would be a hard-fork or implementing an the entire JSON parser. Both are sub-optimal. I'm trying to find a solution that satisfies everyone in the linked PR.

As JamesNK himself wrote that he'd be interested in receiving patches for that, I did so. Sadly, as you said, Json.NET is in maintanence mode and System.Text.Json is its spiritual successor, so I opened a ticket so we can track the status there. If, how and when it is implemented there is subject for discussion. But your posts don't add any value besides being mean.

[FyiurAmron]

I did here and I explicitly ask for feedback/opinion and whether this is a feature to consider. It is also linked above, as I referenced this issue. By seeing your downvote, you already seem to know that this PR exists, so your comment is kinda pointless.

What's your problem, then? You asked for feedback/opinion, and you received it. You asked whether this is a feature to consider. You received an answer. Why do you ask for feedback if you can't bear one?

I'm trying to find a solution that satisfies everyone in the linked PR.

Has it crossed your mind that what you should propose in the PR is the opening of the APIs to be merged (regardless of way, be it de-encapsulation, interfaces, injection), and not a particular implementation? That way, any user requiring this functionality for whatever way would be able to extend, and no user would have to use a non-conforming parser.

As JamesNK himself wrote that he'd be interested in receiving patches for that, I did so

How many PRs are open here? Ca. 50. How many were merged in 2020? 1, in March, a one-line fix. For me, that's the definition of senseless endeavour.

In this issue, OP explicitly asked for JSON5 support in Json.NET:

JSON5 now has inline comments and is thus a far better standard going forward that just needs more support and would be nice if newton supported it.

That makes completely no sense, for a variety of reasons. The fact you jumped the bandwagon doesn't give your position any credibility; it makes you look exactly as silly as OP in this situation.

As JamesNK himself wrote that he'd be interested in receiving patches for that

Yes. 8 years ago. The fact this hasn't been implemented nor merged clearly highlights that, to paraphrase, he _took a look at it and seen how they've done it and whether he thinks it would be useful to others_, and acted accordingly, i.e. skipped this completely.

your posts don't add any value besides being mean.

You asked for opinions, you got one. You also got a bunch of facts and references you are too lazy to even consider or reply to in an organized manner. Just because you disagree with them doesn't mean you're right. Again, to reiterate: worst case scenario, my posts add exactly the same value as yours and your code - zero.

That will be my last comment answering you. You are just too mean without any reason.

Problems on the memory lane? :} :100: