Skip to content
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

DISCUSSION DRAFT: Facility to support dependency-free JSON, System.Text.Json, and Newtonsoft.Json #93

Closed

Conversation

sblom
Copy link
Member

@sblom sblom commented Dec 31, 2020

Code to illustrate my thoughts on #65

Current Regressions

  • Lost support for .NET Standard 1.x (even 1.3) because of reflection requirements in TinyJson. This can be overcome.
  • Many tests currently failing. I had almost all of the conformance cases passing with OmniJson in a previous commit. I'll go back and make a pass to fix up broken cases once I get the Newtonsoft implementation finished up.

Overview

This change removes the Newtonsoft.Json dependency from the main project, and replaces it with a home-built facility called 'OmniJson' that provides a similar interface which supports dependency-free JSON by way of TinyJson, or can be enhanced with additional NuGet mix-ins (possibly called json-ld.net.Newtonsoft and json-ld.net.SystemTextJson) that would override OmniJsonToken et al, and provide API methods that expect and return Newtonsoft JTokens or System.Text.Json-backed JSDM values.

@sblom sblom force-pushed the prototype/generic-json-wrapper branch from 5f50bc9 to 991ef99 Compare December 31, 2020 20:16
Copy link
Member

@asbjornu asbjornu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Lost support for .NET Standard 1.x (even 1.3) because of reflection requirements in TinyJson.

Not a huge loss, imho.

This can be overcome.

How?

  • Many tests currently failing. I had almost all of the conformance cases passing with OmniJson in a previous commit. I'll go back and make a pass to fix up broken cases once I get the Newtonsoft implementation finished up.

👍🏼

This change removes the Newtonsoft.Json dependency from the main project, and replaces it with a home-built facility called 'OmniJson' that provides a similar interface which supports dependency-free JSON by way of TinyJson, or can be enhanced with additional NuGet mix-ins (possibly called json-ld.net.Newtonsoft and json-ld.net.SystemTextJson) that would override OmniJsonToken et al, and provide API methods that expect and return Newtonsoft JTokens or System.Text.Json-backed JSDM values.

Besides the naming and some nits regarding the exposed interface, I think this is great. I like that we take ownership of our exposed API and are able to reduce its surface considerably.

Regarding the naming, I think the fact that the types reside within then JsonLD namespace is enough to differentiate them from other serializers and can thus just give the classes names such as JsonArray, JsonObject, etc.


namespace JsonLD.OmniJson
{
public class OmniJsonArray : OmniJsonToken, IList<OmniJsonToken>, IList
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sold on the OmniJson name, but I do like that we take ownership of the external API we provide.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really good point about just calling it JsonLD.Json{Token|Object|Array|Value}. That also helps get me over the other hang-up I had around how much of the Newtonsoft JToken interface(s) I needed to clone. (Exactly to your points below.)


public virtual void CopyTo(OmniJsonToken[] array, int arrayIndex)
{
throw new NotImplementedException();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be better to not implement IList and thus reduce the API surface? IEnumerable is probably sufficient, no?


public virtual OmniJsonToken this[string key] { get => _wrapped.ContainsKey(key) ? Wrap(_wrapped[key]) : null; set => _wrapped[key] = value?.Unwrap(); }

public virtual ICollection<string> Keys => throw new NotImplementedException();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to not implement IDictionary than to throw NotImplementedException, no?

@stale
Copy link

stale bot commented Apr 5, 2021

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 5, 2021
@sblom sblom removed the stale label Apr 14, 2021
@stale
Copy link

stale bot commented Jul 20, 2021

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jul 20, 2021
@sblom sblom removed the stale label Jul 20, 2021
@sblom
Copy link
Member Author

sblom commented Jul 20, 2021

I haven't touched this in a while, but I still believe in the approach. Let me find some time in the next several weeks to update my draft with @asbjornu's feedback.

@stale
Copy link

stale bot commented Oct 19, 2021

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Oct 19, 2021
@stale stale bot closed this Nov 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants