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

New JSON parser in runtime #24

Open
troydai opened this Issue May 12, 2015 · 116 comments

Comments

Projects
None yet
@troydai
Member

troydai commented May 12, 2015

We implemented a new JSON parser in Microsoft.Framework.Runtime and removed the dependency on Newtonsoft.Json.

Using Newtonsoft.Json in the runtime prevents customers from choosing a specific version of Newtonsoft.Json in their applications. This change will allow customers to use any version of Newtonsoft.Json in their applications.

The new JSON parser is customized for internal use. It is used to parse only the project.json, project.lock.json and global.json files.

The new JSON parser doesn't support the following syntax:

  1. Comments in the form of // ... and /* ... */
  2. Trailing commas after the last member of objects and arrays

Other components, such as Microsoft.Framework.PackageManager, still use Newtonsoft.Json to parse JSON files.

@aspnetde

This comment has been minimized.

Show comment
Hide comment
@aspnetde

aspnetde May 12, 2015

Are there any plans to support comments (again)? I think that would be really helpful.

aspnetde commented May 12, 2015

Are there any plans to support comments (again)? I think that would be really helpful.

@LordZoltan

This comment has been minimized.

Show comment
Hide comment
@LordZoltan

LordZoltan May 12, 2015

Yeah while I agree with the change to remove the dependency on NewtonSoft at this low-level, given the importance of these json files, it's perhaps a little naive to assume that they won't need to be annotated with comments for the benefit of humans...
On 12 May 2015 22:05, Thomas Bandt notifications@github.com wrote:Are there any plans to support comments (again)? I think that would be really helpful.

—Reply to this email directly or view it on GitHub.

LordZoltan commented May 12, 2015

Yeah while I agree with the change to remove the dependency on NewtonSoft at this low-level, given the importance of these json files, it's perhaps a little naive to assume that they won't need to be annotated with comments for the benefit of humans...
On 12 May 2015 22:05, Thomas Bandt notifications@github.com wrote:Are there any plans to support comments (again)? I think that would be really helpful.

—Reply to this email directly or view it on GitHub.

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 12, 2015

The lack of comment support is disappointing to say the least. Every developer I know following this was very excited about something with weight finally pushing for JSON comment support. This is really needed across the board - and I think Microsoft has a real opportunity to push adoption here with excellent reasons for doing so.

Every puppet configuration, hiera data file, or settings config we have here at Stack Overflow would benefit from comment support. I really feel you can and should push this. Older tools needing to read such files can run exclude comments via a regex before parsing if needed in the interim.

Please reconsider this. Comments are needed here, and in many, many other similar scenarios. This is an excellent use case to actually advance the JSON spec. Look at it this way: is there anyone who thinks JSON shouldn't support comments?

NickCraver commented May 12, 2015

The lack of comment support is disappointing to say the least. Every developer I know following this was very excited about something with weight finally pushing for JSON comment support. This is really needed across the board - and I think Microsoft has a real opportunity to push adoption here with excellent reasons for doing so.

Every puppet configuration, hiera data file, or settings config we have here at Stack Overflow would benefit from comment support. I really feel you can and should push this. Older tools needing to read such files can run exclude comments via a regex before parsing if needed in the interim.

Please reconsider this. Comments are needed here, and in many, many other similar scenarios. This is an excellent use case to actually advance the JSON spec. Look at it this way: is there anyone who thinks JSON shouldn't support comments?

@stephen-riley

This comment has been minimized.

Show comment
Hide comment
@stephen-riley

stephen-riley May 12, 2015

Re: @NickCraver

is there anyone who things JSON shouldn't support comments?

No. :-)

Seriously, let's make this happen.

stephen-riley commented May 12, 2015

Re: @NickCraver

is there anyone who things JSON shouldn't support comments?

No. :-)

Seriously, let's make this happen.

@Eilon

This comment has been minimized.

Show comment
Hide comment
@Eilon

Eilon May 12, 2015

Member

Hi folks, we're not opposed to adding support for comments - we completely agree they are useful. However, we wanted to start out with a more "pure" solution to reading JSON by following the JSON spec as closely as possible. We currently chose not to implement optional aspects of the spec.

We will certainly revisit support for comments and trailing commas.

Member

Eilon commented May 12, 2015

Hi folks, we're not opposed to adding support for comments - we completely agree they are useful. However, we wanted to start out with a more "pure" solution to reading JSON by following the JSON spec as closely as possible. We currently chose not to implement optional aspects of the spec.

We will certainly revisit support for comments and trailing commas.

@mikeobrien

This comment has been minimized.

Show comment
Hide comment
@mikeobrien

mikeobrien commented May 12, 2015

no sir i dont like it

@vcsjones

This comment has been minimized.

Show comment
Hide comment
@vcsjones

vcsjones May 12, 2015

I'll throw my vote in for supporting comments (trailing commas I can live without). I already have comments in my project.json file, and I would like to keep them. While "optional" I don't think customers will think of it as such. It's quite an omission.

vcsjones commented May 12, 2015

I'll throw my vote in for supporting comments (trailing commas I can live without). I already have comments in my project.json file, and I would like to keep them. While "optional" I don't think customers will think of it as such. It's quite an omission.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 12, 2015

Microsoft should push for comments to be included in the JSON spec. The reasons for it not being included are weak.

And ...

The moment a parser expands the feature set, the document can no longer be parsed by other parsers. It's not at all intuitive that you can comment in project.json but not in bower.json or package.json. This is why it should be part of the spec once again, and why I thought it would be interesting to see how the spec writers would respond to such a request from a large corporation.

See aspnet/Tooling#13 (comment).

@Eilon Is this something that you could discuss with the spec writers?

glen-84 commented May 12, 2015

Microsoft should push for comments to be included in the JSON spec. The reasons for it not being included are weak.

And ...

The moment a parser expands the feature set, the document can no longer be parsed by other parsers. It's not at all intuitive that you can comment in project.json but not in bower.json or package.json. This is why it should be part of the spec once again, and why I thought it would be interesting to see how the spec writers would respond to such a request from a large corporation.

See aspnet/Tooling#13 (comment).

@Eilon Is this something that you could discuss with the spec writers?

@stephen-riley

This comment has been minimized.

Show comment
Hide comment
@stephen-riley

stephen-riley May 12, 2015

@Eilon , totally understand wanting to conform to the spec. However, the grammar for JSON with comments is a strict superset of the official JSON grammar, yes? In that case, what's the harm?

Addressing the link that @glen-84 sent out (good stuff there), we're not asking for VS2015 files to come standard with comments--by all means, leave comments out of the JSON documents that you want to be parseable by standard parsers. We just want the option of including them ourselves in our own files, totally taking on all risk and blame if our files break other parsers. "With great power..." and all that.

stephen-riley commented May 12, 2015

@Eilon , totally understand wanting to conform to the spec. However, the grammar for JSON with comments is a strict superset of the official JSON grammar, yes? In that case, what's the harm?

Addressing the link that @glen-84 sent out (good stuff there), we're not asking for VS2015 files to come standard with comments--by all means, leave comments out of the JSON documents that you want to be parseable by standard parsers. We just want the option of including them ourselves in our own files, totally taking on all risk and blame if our files break other parsers. "With great power..." and all that.

@jbogard

This comment has been minimized.

Show comment
Hide comment
@jbogard

jbogard May 12, 2015

Totally curious, what are you commenting in your project.json file?

jbogard commented May 12, 2015

Totally curious, what are you commenting in your project.json file?

@guardrex

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 12, 2015

Can we have an optional comment element for each section of the project.json schema? At least we would get one line per section ... and it wouldn't break the spec.

guardrex commented May 12, 2015

Can we have an optional comment element for each section of the project.json schema? At least we would get one line per section ... and it wouldn't break the spec.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 12, 2015

@guardrex 👎 That's fugly.

glen-84 commented May 12, 2015

@guardrex 👎 That's fugly.

@Eilon

This comment has been minimized.

Show comment
Hide comment
@Eilon

Eilon May 12, 2015

Member

The problem with comments in JSON files is interoperability with other systems that might read them. For example, even GitHub doesn't like comments in JSON files and they show up like this:

image

That's at the very least ugly, but in potentially worse cases it could mean that some editors/parsers would refuse to parse the file.

Member

Eilon commented May 12, 2015

The problem with comments in JSON files is interoperability with other systems that might read them. For example, even GitHub doesn't like comments in JSON files and they show up like this:

image

That's at the very least ugly, but in potentially worse cases it could mean that some editors/parsers would refuse to parse the file.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 12, 2015

@jbogard,

It could be anything from temporarily removing a dependency, to breaking dependencies into sections, describing what commands do, adding TODOs, etc.

glen-84 commented May 12, 2015

@jbogard,

It could be anything from temporarily removing a dependency, to breaking dependencies into sections, describing what commands do, adding TODOs, etc.

@guardrex

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 12, 2015

@glen-84 Hence the word "optional" in my suggestion. I'm just saying ... if the spec is so all-fire important, then include an optional element in the schema and have the parser skip it. What's the big deal?

guardrex commented May 12, 2015

@glen-84 Hence the word "optional" in my suggestion. I'm just saying ... if the spec is so all-fire important, then include an optional element in the schema and have the parser skip it. What's the big deal?

@kowsheek

This comment has been minimized.

Show comment
Hide comment
@kowsheek

kowsheek May 12, 2015

I've used it to remove temp dependencies as well.

But, as far as JSON goes, it's not technically supposed to have comments in there, so I understand the reasoning. But, we need to find a balance between usage and standard.

There could be a section for "not used" dependencies, similar to exclude.

kowsheek commented May 12, 2015

I've used it to remove temp dependencies as well.

But, as far as JSON goes, it's not technically supposed to have comments in there, so I understand the reasoning. But, we need to find a balance between usage and standard.

There could be a section for "not used" dependencies, similar to exclude.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach May 12, 2015

In the age of DVCS. Why the hell are we still commenting out? You can branch, stash… as many project.json file changes as you can dream of.

danielmarbach commented May 12, 2015

In the age of DVCS. Why the hell are we still commenting out? You can branch, stash… as many project.json file changes as you can dream of.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 12, 2015

@guardrex It just seems like a hack to me.

glen-84 commented May 12, 2015

@guardrex It just seems like a hack to me.

@guardrex

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 12, 2015

@glen-84 It is ... just thinking how it keeps JSON spec cool and gives one line that you can put anything you want into. @danielmarbach I was thinking more along the lines of notes rather than commenting things out.

guardrex commented May 12, 2015

@glen-84 It is ... just thinking how it keeps JSON spec cool and gives one line that you can put anything you want into. @danielmarbach I was thinking more along the lines of notes rather than commenting things out.

@CoreyKaylor

This comment has been minimized.

Show comment
Hide comment
@CoreyKaylor

CoreyKaylor May 12, 2015

Could care less about comments in JSON myself. Easy enough to get back deleted code from a previous commit. Annotate gives context as to why it's there. Odd that I never even considered commenting my *.csproj files either.

CoreyKaylor commented May 12, 2015

Could care less about comments in JSON myself. Easy enough to get back deleted code from a previous commit. Annotate gives context as to why it's there. Odd that I never even considered commenting my *.csproj files either.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 12, 2015

@kowsheek, that's just one use case. I would not extend the schema for something like that.

glen-84 commented May 12, 2015

@kowsheek, that's just one use case. I would not extend the schema for something like that.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 12, 2015

@danielmarbach, You seriously branch/stash and revert each time you comment in a C# file? o.O

glen-84 commented May 12, 2015

@danielmarbach, You seriously branch/stash and revert each time you comment in a C# file? o.O

@kowsheek

This comment has been minimized.

Show comment
Hide comment
@kowsheek

kowsheek May 12, 2015

@glen-84 true.

@danielmarbach Naah, sometimes you're in the middle of something and it comes in handy to comment out packages.

kowsheek commented May 12, 2015

@glen-84 true.

@danielmarbach Naah, sometimes you're in the middle of something and it comes in handy to comment out packages.

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 12, 2015

@danielmarbach Commenting out is not used just for disabling code & components. Think about the default web.config in vCurrent for example: "here's how you would do X". I would be using this in all my example configuration files for projects of pieces you can enable/change/etc. if JSON supported it already. DVCS is really an orthogonal concern to the many use cases here.

NickCraver commented May 12, 2015

@danielmarbach Commenting out is not used just for disabling code & components. Think about the default web.config in vCurrent for example: "here's how you would do X". I would be using this in all my example configuration files for projects of pieces you can enable/change/etc. if JSON supported it already. DVCS is really an orthogonal concern to the many use cases here.

@danielmarbach

This comment has been minimized.

Show comment
Hide comment
@danielmarbach

danielmarbach May 12, 2015

Stage, stash, done

Am 13.05.2015 um 00:01 schrieb Kowsheek Mahmood notifications@github.com:

@glen-84 true.

@danielmarbach Naah, sometimes you're in the middle of something and it comes in handy to comment out packages.


Reply to this email directly or view it on GitHub.

danielmarbach commented May 12, 2015

Stage, stash, done

Am 13.05.2015 um 00:01 schrieb Kowsheek Mahmood notifications@github.com:

@glen-84 true.

@danielmarbach Naah, sometimes you're in the middle of something and it comes in handy to comment out packages.


Reply to this email directly or view it on GitHub.

@guardrex

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 12, 2015

What's the current thinking on having normal comments /* */ and/or // and using Gulp to strip them out prior to project.json being parsed? I see a gulp-strip-json-comments plugin, but I don't know how to fire it off prior to project.json getting parsed. Can it be done?

guardrex commented May 12, 2015

What's the current thinking on having normal comments /* */ and/or // and using Gulp to strip them out prior to project.json being parsed? I see a gulp-strip-json-comments plugin, but I don't know how to fire it off prior to project.json getting parsed. Can it be done?

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl
Member

davidfowl commented May 12, 2015

No

@mgravell

This comment has been minimized.

Show comment
Hide comment
@mgravell

mgravell May 12, 2015

@danielmarbach by that logic: we shouldn't have comments in code either :) it isn't about deleting stuff; it is about commenting - why something is what it is, why it can't be something else - something unobvious that the reader should know

mgravell commented May 12, 2015

@danielmarbach by that logic: we shouldn't have comments in code either :) it isn't about deleting stuff; it is about commenting - why something is what it is, why it can't be something else - something unobvious that the reader should know

@guardrex

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 12, 2015

Rats! 🐀 🐀 🐀

guardrex commented May 12, 2015

Rats! 🐀 🐀 🐀

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 12, 2015

Member

Lets just all go force the JSON spec to support comments 😄 Bike shedding on this github announcement is pretty useless. I think we all understand people want comments.

Member

davidfowl commented May 12, 2015

Lets just all go force the JSON spec to support comments 😄 Bike shedding on this github announcement is pretty useless. I think we all understand people want comments.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 12, 2015

@davidfowl 👍 ... but like I said, a request/proposal from a large corporation would carry a lot more weight than one from a lone developer.

glen-84 commented May 12, 2015

@davidfowl 👍 ... but like I said, a request/proposal from a large corporation would carry a lot more weight than one from a lone developer.

@mj1856

This comment has been minimized.

Show comment
Hide comment
@mj1856

mj1856 May 12, 2015

If comments were to be supported, how would they play nice with tooling? I would think they could be easily mutilated or lost.

mj1856 commented May 12, 2015

If comments were to be supported, how would they play nice with tooling? I would think they could be easily mutilated or lost.

@kowsheek

This comment has been minimized.

Show comment
Hide comment
@kowsheek

kowsheek May 12, 2015

With @davidfowl for this one. JSON specs don't allow comments, since JSON is built for data-interchange. I'm sure we won't miss it as much as all these comments here.

kowsheek commented May 12, 2015

With @davidfowl for this one. JSON specs don't allow comments, since JSON is built for data-interchange. I'm sure we won't miss it as much as all these comments here.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 12, 2015

Or you could just switch to YAML. 😁

glen-84 commented May 12, 2015

Or you could just switch to YAML. 😁

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver May 13, 2015

@davidfowl IMO that's a reasonable approach for the step forward in terms of opting in our out of compatibility with all a tool that doesn't support it. From a realistic standpoint though: whatever new projects are created with I would imagine to be the 99.5% use case with just that.

If there was an easy way to switch in the tooling then it becomes tractable. For example, if you tried added a comment VS could prompt you to switch which would rename the file upon hitting Okay. If the tooling piece like that was in place, I think it's a much better story all around.

NickCraver commented May 13, 2015

@davidfowl IMO that's a reasonable approach for the step forward in terms of opting in our out of compatibility with all a tool that doesn't support it. From a realistic standpoint though: whatever new projects are created with I would imagine to be the 99.5% use case with just that.

If there was an easy way to switch in the tooling then it becomes tractable. For example, if you tried added a comment VS could prompt you to switch which would rename the file upon hitting Okay. If the tooling piece like that was in place, I think it's a much better story all around.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 13, 2015

Member

@glen-84 Sure but that's the nature of the beast. At least this way I can keep the project.json for the most part, but people strictly needing comments can get it working too (as long as there's enough JSON5 parsers in the world).

Member

davidfowl commented May 13, 2015

@glen-84 Sure but that's the nature of the beast. At least this way I can keep the project.json for the most part, but people strictly needing comments can get it working too (as long as there's enough JSON5 parsers in the world).

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 13, 2015

Member

@NickCraver longer term maybe? Short term that wont happen.

Member

davidfowl commented May 13, 2015

@NickCraver longer term maybe? Short term that wont happen.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 13, 2015

@davidfowl BTW, if you have project.json5, the lock file should be project.lock.json5, even if you strip out the comments. This way it can be collapsed in VS and also look consistent.

glen-84 commented May 13, 2015

@davidfowl BTW, if you have project.json5, the lock file should be project.lock.json5, even if you strip out the comments. This way it can be collapsed in VS and also look consistent.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 13, 2015

Member

Sure

Member

davidfowl commented May 13, 2015

Sure

@SeanKilleen

This comment has been minimized.

Show comment
Hide comment
@SeanKilleen

SeanKilleen May 13, 2015

👍 this seems like a great idea. For most who don't need comments, they'd see no change. For those who do, a rename to json5 allows comments. And, it sounds like it stays true to the specs of both from what I've read here. Yes, it could be slightly confusing but my guess is that most won't come into contact with it.

Though I have to say, given that, it seems to make sense to just default it to .json5. Allows comments from the outset, and anyone confused by the additional digit can google it. Remains true to its spec and allows things that folks might need.

Informative discussion by the way; Thanks!

SeanKilleen commented May 13, 2015

👍 this seems like a great idea. For most who don't need comments, they'd see no change. For those who do, a rename to json5 allows comments. And, it sounds like it stays true to the specs of both from what I've read here. Yes, it could be slightly confusing but my guess is that most won't come into contact with it.

Though I have to say, given that, it seems to make sense to just default it to .json5. Allows comments from the outset, and anyone confused by the additional digit can google it. Remains true to its spec and allows things that folks might need.

Informative discussion by the way; Thanks!

@Matthew-Bonner

This comment has been minimized.

Show comment
Hide comment
@Matthew-Bonner

Matthew-Bonner May 13, 2015

I guess we have moved on but still...
https://github.com/aspnet/Home/wiki/Project.json-file#configurations

Understandable that supporting JSON5 is something to be considered in respect of commenting, but VS reads and writes to these files, and I know I said earlier about supporting many formats but as you have clarified my comment is no longer relevant, so for the basis of the project.json if you have multiple formats does this not throw a few spanners in the works?

Consider the following, there is a project.json and a project.json5 file, which does VS prefer when it needs to make changes?

Also, despite making changes to the file myself, I can't see a huge benefit in supporting comments, and making the jump to support JSON5 is to me a bigger investment than some are considering, so is it really worth the time?

Matthew-Bonner commented May 13, 2015

I guess we have moved on but still...
https://github.com/aspnet/Home/wiki/Project.json-file#configurations

Understandable that supporting JSON5 is something to be considered in respect of commenting, but VS reads and writes to these files, and I know I said earlier about supporting many formats but as you have clarified my comment is no longer relevant, so for the basis of the project.json if you have multiple formats does this not throw a few spanners in the works?

Consider the following, there is a project.json and a project.json5 file, which does VS prefer when it needs to make changes?

Also, despite making changes to the file myself, I can't see a huge benefit in supporting comments, and making the jump to support JSON5 is to me a bigger investment than some are considering, so is it really worth the time?

@PureKrome

This comment has been minimized.

Show comment
Hide comment
@PureKrome

PureKrome commented May 13, 2015

image

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 13, 2015

Member

@Matthew-Bonner nothing is set in stone, it was a straw man proposal to see if anyone though it was a good idea. We can't promise anything but we'll look at some options and see if anything is viable.

Member

davidfowl commented May 13, 2015

@Matthew-Bonner nothing is set in stone, it was a straw man proposal to see if anyone though it was a good idea. We can't promise anything but we'll look at some options and see if anything is viable.

@nil4

This comment has been minimized.

Show comment
Hide comment
@nil4

nil4 May 13, 2015

@davidfowl you seem to be open to the idea of supporting JSON5 file formats, which is great, and I want to add a 👍. My understanding is that this change would imply updating dnx, nuget and VS tooling to be fully supported. Does this mean that the ship has sailed argument against renaming project.json (and perhaps global.json) to something more sensible in aspnet/dnx#1817 could still be reconsidered?

nil4 commented May 13, 2015

@davidfowl you seem to be open to the idea of supporting JSON5 file formats, which is great, and I want to add a 👍. My understanding is that this change would imply updating dnx, nuget and VS tooling to be fully supported. Does this mean that the ship has sailed argument against renaming project.json (and perhaps global.json) to something more sensible in aspnet/dnx#1817 could still be reconsidered?

@vcsjones

This comment has been minimized.

Show comment
Hide comment
@vcsjones

vcsjones May 13, 2015

The more I think on the issue, the more I am willing to let go of comments in favor of following a specification. Two files to accomplish the same thing is, frankly, insane. Here we have a "clean slate" to do things right and simple, and this doesn't seem to align with that goal. If it's too late to change which specification we use, then I am happy to leave out comments. I can already see this conversation:

Q: Why is there a project.json and project.json5 option for my project?
A: The json5 file lets you use comments. Other than that, it is the same purpose.
Q: Oh. So I should use json5 for my config file then if I want comments?
A: Er, no. That uses json as well, but it allows comments.
Q: Oh, well, why doesn't the regular project.json file support comments like my config file does without this json5 stuff?

That just seems... awkward.

For what it is worth, I think it would also be strange to say the project.json file doesn't allow comments, but configuration files do. They are the same format, right? Why are they handled differently? Unless you were involved in this conversation, people will probably chalk it up as some stupid quirk that might get fixed eventually.

This is why I think comments should just be supported with plain json. Yes, it doesn't follow the spec, but it at least follows people's expectations, and is consistent with how the rest of the framework handles json files, like configuration. If that option is off the table, then I'll go sans comments.

My approach to this is probably wrong. Maybe I think I need comments, when there is something better that I am missing, so let me explain why I think I need them, and perhaps someone can tell me why I am wrong.

I was quite looking forward to comments in project.json because it lets me add comments and history about the project in places that ASP.NET projects don't let you today. One particular example of that is depending on an old version of a nuget package. We Had a dependency on package, let's call it Frob, and used version 1.2, however there were newer versions on nuget. The new versions contained a subtle bug that was preventing us from upgrading until it was fixed.

In a project today, there is no really good place to visibly capture that. The .csproj files are almost never looked at in their XML form except when merging, and are a poor place to annotate anything. Eventually someone would see in the Nuget package manager, "oh an update, I'll go ahead and update it" and then unit tests would break, and we'd have to communicate it - again. However with the .json file, we can just stick a comment next to our dependency: "//Do not upgrade beyond 1.2, newer versions have a bug we are waiting on a fix for."

We could have set up our own nuget feed that only has the exact versions of the nuget packages we want, but that "enterprise" approach felt heavy handed for what is just a minor problem.

Perhaps there is a better way to address the above without using comments.

vcsjones commented May 13, 2015

The more I think on the issue, the more I am willing to let go of comments in favor of following a specification. Two files to accomplish the same thing is, frankly, insane. Here we have a "clean slate" to do things right and simple, and this doesn't seem to align with that goal. If it's too late to change which specification we use, then I am happy to leave out comments. I can already see this conversation:

Q: Why is there a project.json and project.json5 option for my project?
A: The json5 file lets you use comments. Other than that, it is the same purpose.
Q: Oh. So I should use json5 for my config file then if I want comments?
A: Er, no. That uses json as well, but it allows comments.
Q: Oh, well, why doesn't the regular project.json file support comments like my config file does without this json5 stuff?

That just seems... awkward.

For what it is worth, I think it would also be strange to say the project.json file doesn't allow comments, but configuration files do. They are the same format, right? Why are they handled differently? Unless you were involved in this conversation, people will probably chalk it up as some stupid quirk that might get fixed eventually.

This is why I think comments should just be supported with plain json. Yes, it doesn't follow the spec, but it at least follows people's expectations, and is consistent with how the rest of the framework handles json files, like configuration. If that option is off the table, then I'll go sans comments.

My approach to this is probably wrong. Maybe I think I need comments, when there is something better that I am missing, so let me explain why I think I need them, and perhaps someone can tell me why I am wrong.

I was quite looking forward to comments in project.json because it lets me add comments and history about the project in places that ASP.NET projects don't let you today. One particular example of that is depending on an old version of a nuget package. We Had a dependency on package, let's call it Frob, and used version 1.2, however there were newer versions on nuget. The new versions contained a subtle bug that was preventing us from upgrading until it was fixed.

In a project today, there is no really good place to visibly capture that. The .csproj files are almost never looked at in their XML form except when merging, and are a poor place to annotate anything. Eventually someone would see in the Nuget package manager, "oh an update, I'll go ahead and update it" and then unit tests would break, and we'd have to communicate it - again. However with the .json file, we can just stick a comment next to our dependency: "//Do not upgrade beyond 1.2, newer versions have a bug we are waiting on a fix for."

We could have set up our own nuget feed that only has the exact versions of the nuget packages we want, but that "enterprise" approach felt heavy handed for what is just a minor problem.

Perhaps there is a better way to address the above without using comments.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 13, 2015

Member

@nil4 Nah we're not renaming it at this point.

Member

davidfowl commented May 13, 2015

@nil4 Nah we're not renaming it at this point.

@LordZoltan

This comment has been minimized.

Show comment
Hide comment
@LordZoltan

LordZoltan May 13, 2015

I'm going to be a total wimp here and backtrack on everything else I've said, although I guess that's what discussions are all about!
I'd like comments, but I'd rather not have to choose formats based on whether I want comments, not least because I fear for the IDE experience.  It's not that important to me.
So, in my very humble of opinions, if it's a choice between no comments or a choice of file formats, it'd be the former.
It's possibly the best solution to those for whom comments are a must, though - so kudos there.
On 13 May 2015 12:43 pm, David Fowler notifications@github.com wrote:@Matthew-Bonner nothing is set in stone, it was a straw man proposal to see if anyone though it was a good idea. We can't promise anything but we'll look at some options and see if anything is viable.

—Reply to this email directly or view it on GitHub.

LordZoltan commented May 13, 2015

I'm going to be a total wimp here and backtrack on everything else I've said, although I guess that's what discussions are all about!
I'd like comments, but I'd rather not have to choose formats based on whether I want comments, not least because I fear for the IDE experience.  It's not that important to me.
So, in my very humble of opinions, if it's a choice between no comments or a choice of file formats, it'd be the former.
It's possibly the best solution to those for whom comments are a must, though - so kudos there.
On 13 May 2015 12:43 pm, David Fowler notifications@github.com wrote:@Matthew-Bonner nothing is set in stone, it was a straw man proposal to see if anyone though it was a good idea. We can't promise anything but we'll look at some options and see if anything is viable.

—Reply to this email directly or view it on GitHub.

@tbertenshaw

This comment has been minimized.

Show comment
Hide comment
@tbertenshaw

tbertenshaw May 13, 2015

@davidfowl What about if someone adds a project.json5 , upon save it runs the json5 converter to overright the project.json? Similar functionality to nested js and min.js files?

tbertenshaw commented May 13, 2015

@davidfowl What about if someone adds a project.json5 , upon save it runs the json5 converter to overright the project.json? Similar functionality to nested js and min.js files?

@mrtaikandi

This comment has been minimized.

Show comment
Hide comment
@mrtaikandi

mrtaikandi May 13, 2015

I don't get it. Before changing the parser there were comments and no mention of json5, two type of files, their extensions and their impact.

So why not do the same? Why not just implement a "partial json5" parser and leave everything else as it is right now?

mrtaikandi commented May 13, 2015

I don't get it. Before changing the parser there were comments and no mention of json5, two type of files, their extensions and their impact.

So why not do the same? Why not just implement a "partial json5" parser and leave everything else as it is right now?

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 13, 2015

@davidfowl What about if someone adds a project.json5 , upon save it runs the json5 converter to overright the project.json? Similar functionality to nested js and min.js files?

Too much magic which would only work in VS, IMHO.

glen-84 commented May 13, 2015

@davidfowl What about if someone adds a project.json5 , upon save it runs the json5 converter to overright the project.json? Similar functionality to nested js and min.js files?

Too much magic which would only work in VS, IMHO.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 13, 2015

So why not do the same? Why not just implement a "partial json5" parser and leave everything else as it is right now?

Because you should be able to read a *.json file with any spec-compliant parser. If you add comments, you break existing tools and parsers.

In my opinion, the choice should be between project.json without comments and project.json5 (or similar) with comments.

glen-84 commented May 13, 2015

So why not do the same? Why not just implement a "partial json5" parser and leave everything else as it is right now?

Because you should be able to read a *.json file with any spec-compliant parser. If you add comments, you break existing tools and parsers.

In my opinion, the choice should be between project.json without comments and project.json5 (or similar) with comments.

@mariusschulz

This comment has been minimized.

Show comment
Hide comment
@mariusschulz

mariusschulz commented May 13, 2015

@glen-84 👍

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 13, 2015

What makes this even more tricky is that if a decision was made to use something like JSON5, people would also want to use it for their configuration files. In such case, there would have to be two implementations, in order to avoid the same potential version conflicts that motivated the development of this JSON parser in the first place.

For this reason, if comments are deemed necessary by the ASP.NET team (perhaps after gathering feedback), it may make more sense to create a simple custom project file format that just adds comment support to a JSON-like document, and uses a different file extension like *.dnx (f.e. project.dnx).

The issue then would be editor support, as the editor would need to understand three file types (json, json5, and dnx). Perhaps just supporting strict JSON and JSON5 would be more viable.

glen-84 commented May 13, 2015

What makes this even more tricky is that if a decision was made to use something like JSON5, people would also want to use it for their configuration files. In such case, there would have to be two implementations, in order to avoid the same potential version conflicts that motivated the development of this JSON parser in the first place.

For this reason, if comments are deemed necessary by the ASP.NET team (perhaps after gathering feedback), it may make more sense to create a simple custom project file format that just adds comment support to a JSON-like document, and uses a different file extension like *.dnx (f.e. project.dnx).

The issue then would be editor support, as the editor would need to understand three file types (json, json5, and dnx). Perhaps just supporting strict JSON and JSON5 would be more viable.

@rajajhansi

This comment has been minimized.

Show comment
Hide comment
@rajajhansi

rajajhansi May 13, 2015

I vote for a single format i.e., project.json5. Even thought I don't use *nix and OSX, as long as VS2015 and the command line tool dnvm that uses project.json5 parses it correctly and MS ships the json5 parser,IDE and command line tools, what is the issue? Btw, VS still uses .sln, a file that command line tools don't care about.

rajajhansi commented May 13, 2015

I vote for a single format i.e., project.json5. Even thought I don't use *nix and OSX, as long as VS2015 and the command line tool dnvm that uses project.json5 parses it correctly and MS ships the json5 parser,IDE and command line tools, what is the issue? Btw, VS still uses .sln, a file that command line tools don't care about.

@sebastiang

This comment has been minimized.

Show comment
Hide comment
@sebastiang

sebastiang May 13, 2015

You should totally use XML! It has support for comments! It could look something like this

<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Reference Include="System.Reactive.Linq" />
    <Compile Include="ApplicationTest.cs" />
    ...

sebastiang commented May 13, 2015

You should totally use XML! It has support for comments! It could look something like this

<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Reference Include="System.Reactive.Linq" />
    <Compile Include="ApplicationTest.cs" />
    ...
@FransBouma

This comment has been minimized.

Show comment
Hide comment
@FransBouma

FransBouma May 13, 2015

Man, the progress made with these new formats. XML had comments since before the first world war, and was perfectly fine as a project format. Opting for 'json' is not making more things possible, but less things possible. I.o.w.: it's limiting. While there are so many other formats out there which don't force these limits onto you.

I find it rather funny that there are people in this thread who spent a tremendous amount of energy to apologize for them being limited by this format. "It's a good thing!". Sure it is, in your world, but you're not everyone, and this is for everyone.

FransBouma commented May 13, 2015

Man, the progress made with these new formats. XML had comments since before the first world war, and was perfectly fine as a project format. Opting for 'json' is not making more things possible, but less things possible. I.o.w.: it's limiting. While there are so many other formats out there which don't force these limits onto you.

I find it rather funny that there are people in this thread who spent a tremendous amount of energy to apologize for them being limited by this format. "It's a good thing!". Sure it is, in your world, but you're not everyone, and this is for everyone.

@gregoryyoung

This comment has been minimized.

Show comment
Hide comment
@gregoryyoung

gregoryyoung May 13, 2015

We implemented a new JSON parser in Microsoft.Framework.Runtime and removed the dependency on Newtonsoft.Json.

"Using Newtonsoft.Json in the runtime prevents customers from choosing a specific version of Newtonsoft.Json in their applications. This change will allow customers to use any version of Newtonsoft.Json in their applications."

Why not just internalize the dependency in which case the problem would go away?

gregoryyoung commented May 13, 2015

We implemented a new JSON parser in Microsoft.Framework.Runtime and removed the dependency on Newtonsoft.Json.

"Using Newtonsoft.Json in the runtime prevents customers from choosing a specific version of Newtonsoft.Json in their applications. This change will allow customers to use any version of Newtonsoft.Json in their applications."

Why not just internalize the dependency in which case the problem would go away?

@markrendle

This comment has been minimized.

Show comment
Hide comment
@markrendle

markrendle May 13, 2015

Sod JSON. Use MOFO.

👋
🎤

markrendle commented May 13, 2015

Sod JSON. Use MOFO.

👋
🎤

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 13, 2015

@gregoryyoung,

darkangel: That would be fixed by internal deps one day maybe.     1:54:01 PM
davidfowl: yea if you want to internalize 900 KB                   1:54:22 PM
davidfowl: or however big json.net is                              1:54:27 PM
davidfowl: when all you need a super simple JSON DOM               1:54:37 PM
darkangel: sure                                                    1:54:44 PM
darkangel: Trade offs.                                             1:54:49 PM

glen-84 commented May 13, 2015

@gregoryyoung,

darkangel: That would be fixed by internal deps one day maybe.     1:54:01 PM
davidfowl: yea if you want to internalize 900 KB                   1:54:22 PM
davidfowl: or however big json.net is                              1:54:27 PM
davidfowl: when all you need a super simple JSON DOM               1:54:37 PM
darkangel: sure                                                    1:54:44 PM
darkangel: Trade offs.                                             1:54:49 PM
@daveaglick

This comment has been minimized.

Show comment
Hide comment
@daveaglick

daveaglick May 13, 2015

I'm with @FransBouma. I understand the desire to get away from XML, like just about everyone else I'm not a huge fan of it's verbose syntax. For that matter, I'm not a huge fan of the quotes-everywhere nature of JSON either. But ending up with a solution that has fewer features than what we're leaving behind in the name of syntax seems...odd. I don't know what the best language would be, but I'm guessing it's a moot point because the JSON vs. YAML vs. HipsterMarkupOfTheMonth discussions happened a while ago?

That said, if JSON is "it" I would advocate for some way to keep the commenting ability. Remember that this is .NET and there is a huge enterprise userbase out there that will be adopting these new technologies with all kinds of different use cases, conventions, etc. Most aren't on GitHub, Jabbr, etc. but I suspect at least some currently use and would like to continue using comments in their various configuration and project artifacts.

daveaglick commented May 13, 2015

I'm with @FransBouma. I understand the desire to get away from XML, like just about everyone else I'm not a huge fan of it's verbose syntax. For that matter, I'm not a huge fan of the quotes-everywhere nature of JSON either. But ending up with a solution that has fewer features than what we're leaving behind in the name of syntax seems...odd. I don't know what the best language would be, but I'm guessing it's a moot point because the JSON vs. YAML vs. HipsterMarkupOfTheMonth discussions happened a while ago?

That said, if JSON is "it" I would advocate for some way to keep the commenting ability. Remember that this is .NET and there is a huge enterprise userbase out there that will be adopting these new technologies with all kinds of different use cases, conventions, etc. Most aren't on GitHub, Jabbr, etc. but I suspect at least some currently use and would like to continue using comments in their various configuration and project artifacts.

@haneytron

This comment has been minimized.

Show comment
Hide comment
@haneytron

haneytron May 13, 2015

I agree fully with @daveaglick - but I must say that this discussion is the greatest example of Parkinson's Law of Triviality I've seen in a long time. Does it really matter that much in the grand scheme of vNext changes? I feel we should all consider the importance of this change relative to everything else.

haneytron commented May 13, 2015

I agree fully with @daveaglick - but I must say that this discussion is the greatest example of Parkinson's Law of Triviality I've seen in a long time. Does it really matter that much in the grand scheme of vNext changes? I feel we should all consider the importance of this change relative to everything else.

@Romoku

This comment has been minimized.

Show comment
Hide comment
@Romoku

Romoku May 13, 2015

JSON is a bunch of name-value pairs. As long as the user can understand what the names and values mean then there is no need for comments.

Romoku commented May 13, 2015

JSON is a bunch of name-value pairs. As long as the user can understand what the names and values mean then there is no need for comments.

@uatec

This comment has been minimized.

Show comment
Hide comment
@uatec

uatec May 13, 2015

I disagree. If i have a list of nuget references, I want to group them and
say "x, y and z are all related to thing M"...

On Wed, 13 May 2015 at 15:28 Romoku notifications@github.com wrote:

JSON is a bunch of name-value pairs. As long as the user can understand
what the keys and values mean then there is no need for comments.


Reply to this email directly or view it on GitHub
#24 (comment)
.

uatec commented May 13, 2015

I disagree. If i have a list of nuget references, I want to group them and
say "x, y and z are all related to thing M"...

On Wed, 13 May 2015 at 15:28 Romoku notifications@github.com wrote:

JSON is a bunch of name-value pairs. As long as the user can understand
what the keys and values mean then there is no need for comments.


Reply to this email directly or view it on GitHub
#24 (comment)
.

@luisrudge

This comment has been minimized.

Show comment
Hide comment
@luisrudge

luisrudge May 13, 2015

👎 For multiple file formats.

luisrudge commented May 13, 2015

👎 For multiple file formats.

@skoon

This comment has been minimized.

Show comment
Hide comment
@skoon

skoon May 13, 2015

Who gives a crap, DEATH TO ALL PROJECT FILES!!!!

skoon commented May 13, 2015

Who gives a crap, DEATH TO ALL PROJECT FILES!!!!

@guardrex

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 13, 2015

👍 for JSON5 as an optional format or the main format. I'll use it with comments.

For those of us in favor, please put votes in at Stephen Cleary's Use JSON5 for project.json at Uservoice.

guardrex commented May 13, 2015

👍 for JSON5 as an optional format or the main format. I'll use it with comments.

For those of us in favor, please put votes in at Stephen Cleary's Use JSON5 for project.json at Uservoice.

@guardrex

This comment has been minimized.

Show comment
Hide comment
@guardrex

guardrex May 13, 2015

Shoutout to Aseem Kishore @aseemk ... at JSON5 on Github.

guardrex commented May 13, 2015

Shoutout to Aseem Kishore @aseemk ... at JSON5 on Github.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 13, 2015

Personally, have two different sets of files will be confusing. I think it needs to be one way or the other. I don't think they do need comments in the 3 files mentioned, but not objective to having them also.

ghost commented May 13, 2015

Personally, have two different sets of files will be confusing. I think it needs to be one way or the other. I don't think they do need comments in the 3 files mentioned, but not objective to having them also.

@MFFoX

This comment has been minimized.

Show comment
Hide comment
@MFFoX

MFFoX May 13, 2015

I have to completely agree with @NickCraver's first comment, specifically

Comments are needed here, and in many, many other similar scenarios. This is an excellent use case to actually advance the JSON spec.

IMHO, it is not your responsibility to keep us honest by enforcing the spec. If other tools don't support comments, then it is our responsibility to go and fight for another implementation, conform our .json to the spec, or stop relying on that tool.

In my eyes, the only reason that would be worth conforming to the spec is because you rely on that functionality. This is not the case. Conforming to a standard just for the sake of conformity is not worth it.

TL;DR my +1 is for comments support and breaking the spec for usability.

MFFoX commented May 13, 2015

I have to completely agree with @NickCraver's first comment, specifically

Comments are needed here, and in many, many other similar scenarios. This is an excellent use case to actually advance the JSON spec.

IMHO, it is not your responsibility to keep us honest by enforcing the spec. If other tools don't support comments, then it is our responsibility to go and fight for another implementation, conform our .json to the spec, or stop relying on that tool.

In my eyes, the only reason that would be worth conforming to the spec is because you rely on that functionality. This is not the case. Conforming to a standard just for the sake of conformity is not worth it.

TL;DR my +1 is for comments support and breaking the spec for usability.

@rossipedia

This comment has been minimized.

Show comment
Hide comment
@rossipedia

rossipedia May 13, 2015

The responses suggesting using git are missing the boat entirely. This isn't about using comments to disable or remove part of the file temporarily, this is about using comments as they are intended: commenting on a part of the file (to add clarity of intent).

I understand why Crockford removed them, I understand they're not part of the spec, but in this case, both are just plain wrong.

rossipedia commented May 13, 2015

The responses suggesting using git are missing the boat entirely. This isn't about using comments to disable or remove part of the file temporarily, this is about using comments as they are intended: commenting on a part of the file (to add clarity of intent).

I understand why Crockford removed them, I understand they're not part of the spec, but in this case, both are just plain wrong.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 13, 2015

TL;DR my +1 is for comments support and breaking the spec for usability.

According to Douglas Crockford:

JSON does not have comments. A JSON encoder MUST NOT output comments.
A JSON decoder MAY accept and ignore comments.

Comments should never be used to transmit anything meaningful. That is
what JSON is for.

In other words (if this idea was included in the spec), it is valid for a decoder to accept and ignore comments.

HOWEVER, in my opinion, it causes unnecessary confusion – why can I comment in project.json but not bower.json or package.json? Also, it breaks in editors and tools that do not support comments. JSON5 also adds a number of other really useful features.

glen-84 commented May 13, 2015

TL;DR my +1 is for comments support and breaking the spec for usability.

According to Douglas Crockford:

JSON does not have comments. A JSON encoder MUST NOT output comments.
A JSON decoder MAY accept and ignore comments.

Comments should never be used to transmit anything meaningful. That is
what JSON is for.

In other words (if this idea was included in the spec), it is valid for a decoder to accept and ignore comments.

HOWEVER, in my opinion, it causes unnecessary confusion – why can I comment in project.json but not bower.json or package.json? Also, it breaks in editors and tools that do not support comments. JSON5 also adds a number of other really useful features.

@MFFoX

This comment has been minimized.

Show comment
Hide comment
@MFFoX

MFFoX May 13, 2015

Comments should never be used to transmit anything meaningful. That is
what JSON is for.

In that case, this is a no brainer. Thanks for including that bit :)

I don't really agree with you about it being confusing. It isn't confusing to me when I try to run a tool that doesn't support comments in json and it errors with an exception to that extent. That's fairly straightforward.

MFFoX commented May 13, 2015

Comments should never be used to transmit anything meaningful. That is
what JSON is for.

In that case, this is a no brainer. Thanks for including that bit :)

I don't really agree with you about it being confusing. It isn't confusing to me when I try to run a tool that doesn't support comments in json and it errors with an exception to that extent. That's fairly straightforward.

@Eilon

This comment has been minimized.

Show comment
Hide comment
@Eilon

Eilon May 13, 2015

Member

Hi everyone,

Wow, what a discussion! We've had similar discussions within the team about supporting comments in the project.json, project.lock.json, and global.json files. We've also discussed whether we should switch to different file formats as an alternative.

Ultimately, we decided that for now it is best to stick with the industry standard JSON format, which has a very well-defined specification. We have chosen JSON for the following reasons:

  1. Well, it's an industry standard. That's pretty neat.
  2. It has support in nearly every tool, web site, editor, parser, which leads to great interoperability.
  3. It is an easy-to-understand, human-readable/writeable, computer-readable/writeable format.
  4. It supports the right set of data structures: arrays, dictionaries, strings, numbers, Booleans.

Though we're not opposed to changing this in the future, this is where we are right now. The purpose of this issue is to announce the change and to see if people had additional thoughts on the effect or consequences of the change. We've carefully read the entire discussion here and will still look at changing this in the future.

I'm now locking this thread because I think the purpose of this thread has been served.

If you have further thoughts on this you can reach me at elipton-AT-microsoft.com.

Thanks,
Eilon Lipton (Engineering Manager for ASP.NET and EntityFramework)

Member

Eilon commented May 13, 2015

Hi everyone,

Wow, what a discussion! We've had similar discussions within the team about supporting comments in the project.json, project.lock.json, and global.json files. We've also discussed whether we should switch to different file formats as an alternative.

Ultimately, we decided that for now it is best to stick with the industry standard JSON format, which has a very well-defined specification. We have chosen JSON for the following reasons:

  1. Well, it's an industry standard. That's pretty neat.
  2. It has support in nearly every tool, web site, editor, parser, which leads to great interoperability.
  3. It is an easy-to-understand, human-readable/writeable, computer-readable/writeable format.
  4. It supports the right set of data structures: arrays, dictionaries, strings, numbers, Booleans.

Though we're not opposed to changing this in the future, this is where we are right now. The purpose of this issue is to announce the change and to see if people had additional thoughts on the effect or consequences of the change. We've carefully read the entire discussion here and will still look at changing this in the future.

I'm now locking this thread because I think the purpose of this thread has been served.

If you have further thoughts on this you can reach me at elipton-AT-microsoft.com.

Thanks,
Eilon Lipton (Engineering Manager for ASP.NET and EntityFramework)

@aspnet aspnet locked and limited conversation to collaborators May 13, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.