Offering some flexibility regarding "relaxed" syntax

Question

Offering some flexibility regarding "relaxed" syntax

sharwell opened this issue 7 years ago · comments

After running into a variety of problems shipping a single binary that worked across numerous runtime environments (including .NET Core scenarios), the StyleCop Analyzers project is now looking at switching to an embedded copy of LightJson rather than depending on Json.NET. However, since this change is targeting a stable release branch, it was essential for us to not break existing users who could be relying on certain aspects of the relaxed syntax allowed by Json.NET, specifically:

Line and block comments (DotNetAnalyzers/StyleCopAnalyzers@1044fee)
Trailing commas (DotNetAnalyzers/StyleCopAnalyzers@27710e6)

Since we took the time to implement this required functionality for LightJson, I wanted to make you aware of the work in case you were interested in bringing it back into the core library. 😄

Marcos Vladimir López Castellanos · Answer 1 · Tue May 30 2017 00:13:27 GMT+0800 (China Standard Time)

Hi @sharwell ,

Thanks for the heads-up. My original goal with this project was to make a parser that would only accept the grammar defined by json.org. I think that it is unwise to allow parsing of non-standard JSON by default. But I'm not opposed to it as long as it's integrated in a way that allows the user to disable the functionality.

Here are 3 solutions that come to mind at the moment:

Add a setting to TextScanner class to tolerate relaxed syntax.
Add a new scanner class that parses the relaxed syntax.
Add a new transducer class that streams in relaxed syntax and streams out filtered, standard JSON.

I'm not sure which one would be the best solution. I would have to do some internal testing. Let me know what you think.

Sam Harwell · Answer 2 · Tue May 30 2017 00:17:23 GMT+0800 (China Standard Time)

@MarcosLopezC Considering how easy it was to embed this, one option would be simply making a note in the readme that points users to this issue if they are looking for such a solution. Based on the way you worded the readme (i.e. "Strict adherence to JSON Standard" as a feature), it seemed like our work was more suited to inclusion as a link than inclusion as updated code.