-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSON literal expressions #101
Comments
JSON.NET is fine. And not to be overdramatic but we would use this every. single. day. |
Then I should get my prototype working again so you can play with it and validate that hypothesis! :) |
@AnthonyDGreen |
Yeah, I should probably just rebase it on the latest sources. |
I had selected the wrong start up project. Needed to use |
Did you rebase on current bits? |
I rebased on master as of two days ago, I think. |
Love it. Great idea |
@AnthonyDGreen What is the syntax for comments? |
I've been using http://json.org/ to define the standard. JSON itself doesn't have a notion of comments and unlike XLinq, I don't think JSON.NET provides a way to encode comments (or whitespace in general). We should discuss forbidding it. Whether a string is a JSON string or a VB String is also an open design question. |
If you're referring to how escaping is done (i.e. |
As @AnthonyDGreen stated, there is no defined standard for comments in JSON. This is quite logical, since the JSON format is mainly intended for data transfer. I am, however, of the notion that this is the greatest injustice done the format. Being a text-based format which is largely human-readable, it is not uncommon to find people creating or tweaking JSON files by hand. For this singular purpose, I believe that having some comments in the format would have been rather helpful. In my case, when editing JSON by hand, I use the C-style multi-line comments (i.e. |
@reduckted absolutely in agreement that the copy/paste principle is paramount for this feature. The problem is that the way the feature is designed right now there is no special syntax that denotes what's a VB expression; whatever isn't a JSON expression is a VB expression. That leads to some weird interactions while typing/exploring: ? { "key": "Line1\r\nLine2" } ' This is a JSON string.
' BUT
? { "key": "Line1\r\nLine2".ToString() } ' This is a VB string. So dotting off of the string, parenthesizing it, etc, could silently make it no longer JSON. We could report a warning on some such cases. Other cases are worse: ? { "key": "Inline \"quotes\" use \"" } ' Everything is fine.
? { "key": "Inline \"quotes\" use \"" } ' Chaos ripples throughout the remainder of the file. Note: If a user does attempt to use Of course, the scenario might be very unlikely and I'd hate to spoil the simplicity of the syntax with some sort of |
I like the idea, and in general I like to use this value pair json syntax to intialize any dectionary or expando object. |
Love the idea... love the video… would definitely use this. I also want to confirm the comment at the very start of this proposal "despite being out of vogue, XML is still in use in tons of businesses and many VB customers I talk to continue to enjoy the feature." as being very true. I'm literally working on a project at this moment where 1/3rd of the third-party API's I'm working with are XML only, 1/3rd are JSON only and 1/3rd give the option of choosing between one or the other. So having the ability to easily interact with JSON (as we have with XML) would be a huge timesaver.
Although there is serious geek cred associated with the implementation you've done where the line is blurred between JSON and VB; I will say that having this sort of syntax makes it clear that you are "doing something" above and beyond the JSON syntax. The "ugly" way is clearly visible and the action doing so doesn't get lost is the sea of JSON. So some more thought should be given that. If I were looking for a "flaw" (as it is really, really, really minor) hiding in what I see it is in the reliance on having to package another assembly. Meaning that if you were to make a small single executable utility, you couldn't do so if utilized this. As I said, a minor issue... but one that doesn't exist with regards to XML literals. ;-) With that said, I'd rather have the "penalty" of have a multiple assembly distributable then not having the choice at all for the ease of use. All-in-all this is really awesome! |
Please look at this proposal https://github.com/dotnet/roslyn/issues/38274 . It will allow strongly typed JSON and XML settings. |
Re: comments, I assume we aren't suggesting that we produce JSON with comments in it (this would be invalid JSON). I assume the question is how to add VB comments in middle of a JSON literal. I assume this would be done in the regular way? Dim name = {
"first": "Anthony", 'Former VB PM
"last": "Green"
} Of course there would be no way to do this all in one line, but that's a longstanding limitation of VB's not having inline ( |
With _ ' Comment you can get very closer and the feature could be expanded to work in more places but if you want a single line solution I have not thought of a non-breaking way since anything is allowed after a ' until EOL |
Despite being out of vogue, XML is still in use in tons of businesses and many VB customers I talk to continue to enjoy the feature. It's natural to ask whether we can duplicate the wins here with JSON. I was a little hesitant on JSON until I saw that SQL Server 2016 has built-in JSON support.
I've implemented a working prototype here though it's out of date and needs updating to work with the latest Roslyn sources/VS2017. It's build around JSON.NET. The syntax is just JSON:
And like XML it supports embedded expressions:
Any value not native to JSON (string, number, JSON object, JSON array, true, false, null) is an embedded expression:
Any key not a string is an embedded expression.
Any member not a key-value-pair is an embedded expression.
The big "win" uses I imagine are copying and pasting a JSON example/message from some website into your code and then substituting in your own dynamic values with embedded expressions. I hope this could be a powerful tool for communicating to REST services since users won't have to create separate POCO objects and serialize them or manually construct JSON.NET JObjects:
The second big win use is pairing JSON literals with pattern matching, enabling the developer to decompose a JObject off the wire without deserializing to a .NET Object.
No need for any special member access syntax since the ! operator works natively with JSON.NET objects. We should consider some sort of pattern-based support so the feature could target either JSON.NET or Windows.Data.Json but if we can only do one, JSON.NET is preferred.
The text was updated successfully, but these errors were encountered: