Hacker News Reader

Comment by bad_user | Hacker News Reader

One needs a way to override the deserialization though, as often the correspondence between that JSON map and the fields on Person is not exactly one to one - starting with something as simple as having camelCase in your Dart code and underscores in your JSON. Of course, it's not that hard to build such a library and it's fairly useful too.

View on HN

This is invented complexity; there is no need to support this in order to satisfy the majority of requirements.

Just because requirements can be made complicated doesn't mean there should be no support for something simple.

The built-in .NET JSON serialise is very limited; and there are third party libraries (even used by MS themselves for ASP.NET) to address that.

In my experience, in most cases I've encountered, the serialization/deserialization schema does need a few simple tweaks, mostly because JSON is a format used for interoperability (and you can't necessarily force the same conventions everywhere) and for APIs that change over time. And it's useful to be able to make minor tweaks to those conventions - otherwise you've got to chose between something super easy (based on reflection) or something that interprets a map and that ends up looking like vomit copy pasted from the Internet.

I'm against super complex things, but things going into a standard library should be general enough for 80% of the use-cases in the wild (and no, I don't agree with you here), otherwise it's very hard to make changes in the standard library later, therefore instead of pushing for something half-baked, I would rather wait for third-parties to build such a library.

Scala for example has a shitty JSON parser in the standard library that nowadays nobody uses because it is limited and because third-party libraries are better. I suspect, from what you're telling me, that C#'s standard parser is in the same league.

Reply on news.ycombinator.com