-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Open up metadata infrastructure of System.Text.Json #34456
Labels
Milestone
Comments
Related seems to be this comment from @layomia #2202 (comment) |
This overlaps a bit with #36785. Currently evaluating 5.0 plan. |
Moving to Future; will address when we have a single story for metadata and improved object\collection converters. |
5 tasks
This was referenced Jul 22, 2021
Closing in favor of #63686. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Today STJ does a lot of introspection like any other serializer to create fast getter/setters, find matching constructors and other things like it.
What would be very helpful — to provide better tools for custom converter writers — is to make public the internal code that handles logic like constructor matching, visible properties (shadowed members etc).
As an example, idiomatic F# records don't have an empty default constructor, writing code to match a constructor to the properties that were read is fairly finicky (and frankly tedious), especially if you'd want this to match STJ behavior exactly.
Another example that benefits from having more of this infra be public is OData like types where there is a typed object that also contains one dictionary property named Properties that stores all the unknown/dynamic props.
This means taking control over serializing potentially 'any' type, to keep a cache of all names and values, if unknown add it to the Properties dictionary, finally write this all into the object, either via fast setters, or via a matching constructor, preferably taking into account property visibility too.
I write from experience, this is also no fun in Newtonsoft where I similarly miss these apis.
It must be easier to harness metadata infrastructure STJ uses itself like ReflectionMemberAccessor, logic for finding a matching constructor etcetera. In my opinion this should be part of the public api of a good serializer.
The text was updated successfully, but these errors were encountered: