This seems like a non-issue to me. Serialization isn't built into the core libraries, but there are a number of 3rd party libraries that will serialize from various data formats. Dart has mirrors (reflection) which allows any kind of population of Dart types from other data types.
Justin Fagnani's response hits it head on. It makes no sense to deserialize schema-less JSON into objects. How is the compiler to know what classes you want it to use? Even if you just want classes with no methods, the deserializer still needs to know what fields you expect. (Otherwise you have no guarantee what fields the object you're returned has, which is pretty useless!)<p>Even more, what if you really want a JSON object to be deserialized as a key-value map, not an object? (Those support different functionality!) The compiler has no way of knowing this.<p>Either you need to provide a schema, in which case it's easy to make a library to deserialize objects, or you're asking for something ill-defined.
I think many people are satisfied with the alternatives presented in that thread. A very large percentage will probably even be happy with the serialization to Lists and Maps - because that is what JavaScript already does! I understand that you have your preferences, and you are entitled to have those. In my opinion, you are not entitled to:<p>- Present your complaints as though Dart is missing basic functionality (not in the presence of the presented alternatives). It just misses <i>your specific</i> desired functionality!<p>- Assume your use case is representative for a significant amount of other developers.<p>- Extend your entitlement to the HN front page.<p>C# JSON support appears to be awesome, and you are very free to make a Dart library that does exactly that. You are also free to request it to be merged into the core Dart libraries [1]. You are not free, in my opinion, to drag out this complaint so much.<p>As a reference, here's a list of other typed languages that don't support JSON deserialization-to-classes in their core libraries:<p>- Java (Scala, Groovy, Xtend, etc...)<p>- GWT Java<p>- Kotlin (both on JVM <i>and</i> in browser)<p>- Ceylon<p>- C++<p>- OCaml<p>- Swift<p>- ...<p>Seeing those languages are often used to consume web services, it seems Dart is in good company. There's probably a good reason why this stuff is relegated to third party libraries. I'd speculate that 1) accomplishing this is messy and complex in the context of type safety and 2) the problem you are complaining about simply isn't as big as you think it is.<p>[1]: <a href="https://code.google.com/p/dart/wiki/Contributing" rel="nofollow">https://code.google.com/p/dart/wiki/Contributing</a>
It seems to me the author should think twice about rewriting an entire code base in a new language. This almost always leads to disaster, and often doesnt give you a lot of value.<p>Also he is pointing out, that he doesnt want to use 3rd party libraries. I worked with people who said that before... This breaks the whole idea of writing software by standing on the shoulders of giants. When you write an app, you almost ALWAYS use libraries (and they are not written by you). Writing a complete app just with the core language tools seems like total nonsense to me.. Why woudnt you use a library that solves the job for you?<p>You should off course try to prevent entangling dependency of a lib into your code base. But thats a basic rule of software engineering.<p>B.t.w, with testing, you can mock away those libraries and still have nice unit tests.
One thing Haxe does well here is provide structural typing, effectively letting you declare the result of a deserialization process in type form.<p>This isn't perfect... you still need to know in advance what kinds of object structures are possible, but generally this isn't too much to ask (e.g. relying on a server api to provide consistent records).<p>The next catch is that you can't treat these structural type results like typical classes. E.g., you can't have methods, getter/setter logic, etc. However, you can attach relevant methods with a special mixin directive (that does not alter the runtime object).<p>In this way, I have a pretty good way of providing a robust description of server responses in terms of type information, and a good way of loosely binding these responses to relevant methods.
I'm not familiar with Dart, but it seems like since it has object(map)/list literal syntax similar to Javascript, deserializing a simple object (no methods) from a string of characters would be trivial. JSON really is a Javascript killer feature imo.
The stupidity of the question is causing me to have neural pathway executions that are akin to an electoral storm.<p>Actually thinking you could rewrite 1mil loc and end up with something useful is fallacy enough but choosing an experimental language and then complaining about it?