Hacker News Reader

Comment by d2p | Hacker News Reader

The class you're deserialising into is the Schema; exactly like C# manages to do it:

var myPerson = deserialise<Person>(json);

If you want a map, that's already supported; but you'll lose all the "type-safety" that Dart brings!

This may be easier in C# than in Dart because in C#, you have type declarations for all the members. In Dart, type declarations are optional. (And, IIRC, not supposed to change the behavior of the program, except for type-checks performed while running in "development" mode; even these are disabled in "production".)

> If you want a map, that's already supported; but you'll lose all the "type-safety" that Dart brings!

Why are you worried about type-safety? JSON itself only supports object, array, string, number, true/false, and null, so type safety isn't even an issue because invalid JSON will fail to parse. If you're talking about taking a string and regexing it into an address or whatever, then yeah: you should be writing that code yourself.

> Why are you worried about type-safety?

Because that's one of the huge selling points of Dart?!

I would invite you to read the rest of my comment.

I did; but it makes no sense. That's like saying "Why does Dart even both having classes"?.

If you're writing a client application, you probably have data structures. Some of those data structures you need to send to the server (or receive). When you write code that interacts with those structures, you want code-completion; static analysis, etc.; that's kinda the point of Dart's typing!

It's possible to write this deserialize() function in Dart, but its simplicity requires many trade offs for anything other than toy uses, which is why it's not a missing part of the core platform.

Having to choose your serialization strategy is not a bad thing. At the very least, Dart's JSON support is very similar to JavaScript already, and there are several packages that do serialization in different ways.

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.

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.

Why not create yourself a code generator, which analyses the class and generates code to perform the manual map<->object transfer?

Does this not sound like a rather complicated thing for the individual developers to do when 99% of Dart web apps will need to do this?

Sure.

But "99%" of developers just need serialisation, which is supported. You (and myself) want more than that.

Depends on your definition of "supported"? JSON uses maps (throwing away one of the big advantages of Dart) and the Serialisation package appears to rely on hard-coded rules or use mirrors (which are slow and apparently not a good thing to use in production dart2js code).

Reply on news.ycombinator.com