-
Notifications
You must be signed in to change notification settings - Fork 46
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
Support a variant of JsonElementAttributesTable that can be modified in-place, at a cost to reading performance. #118
Conversation
…ot auto-generated by VS Code.
@HarelM This is what I've got for #117. Once it's merged, a prerelease package will automatically be published to https://www.myget.org/feed/nettopologysuite/package/nuget/NetTopologySuite.IO.GeoJSON4STJ. If you wish to provide feedback before then, now is your chance. |
src/NetTopologySuite.IO.GeoJSON4STJ/Converters/GeoJsonConverterFactory.cs
Show resolved
Hide resolved
This looks great! Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @airbreather!
Any chance for an official release with this feature? |
Resolves #117
JsonElementAttributesTable
is just fine as it is, so it hasn't been touched. Instead, I've created a new table type that's backed by the (relatively) new (to us)JsonObject
, from theSystem.Text.Json.Nodes
namespace.This design is optimized for people who want to take an
IFeature
that comes from 4STJ and make relatively few changes to itsAttributes
before handing it off somewhere else.I would have personally preferred if
IFeature
/IAttributesTable
had been read-only, as it seems unlikely that someone actually needs to be able to modify the objects created by our I/O helpers. However, there is at least one consumer who has come to rely on being able to do this in the Newtonsoft.Json version, and so it seems reasonable to provide a more straightforward upgrade path.Especially since, unlike
System.Collections.Generic.ICollection<T>
, we don't document that instances might sometimes be read-only, nor do we give anything likeIsReadOnly
that someone can check to discover whether or not a particular instance can be modified.System.Collections.Generic.ICollection<T>
is almost as bad, to be fair: it does have this documentation andIsReadOnly
that you can check, but based on my experience, I would wager that a typical developer is likely to just assume that every instance ofICollection<T>
is writable (if they even know aboutIsReadOnly
at all!) and write code that's problematic in exactly the same way... but at least there, I could argue that it's their fault for not reading the warning labels...