8 ms·

Google's Dart doesn't support deserialising JSON (or anything) into Dart Types

36 points by d2p 12y ago

clubhi 12y ago
When I was a kid you used to serialize to JSON.
deleted 12y ago
[deleted]
kyrra 12y ago
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.
- d2p 12y ago
  Did you read about any of the suggested options? They all basically suck; requiring tons of boilerplate; are not-static formats (making it difficult to implement "the other side"); poor performance; and mostly implemented by third parties so they'll likely be broken or abandoned in 6 months. Doesn't it seem strange that a Google-designed language for the future of the web (that's supposed to make development faster and easier) doesn't handle this (basic) requirement easily?
  - WoodenChair 12y ago
    I think it would be respectful if you mentioned that you are the starter of the thread on the mailing list in the first place...
    - d2p 12y ago
      Apologies; it's been so long since I signed up, I didn't realise my username was quite so cryptic. The thread is indeed mine, and I posted it here in the hope that it might be seen by someone on the Dart Team, as there seems to have been no response from Google on this hole :(
      - WoodenChair 12y ago
        I can assure you that the Dart team reads the mailing list and has almost certainly seen your thread there. I appreciate (and can see) that you honestly want to help Dart succeed, but the title of this thread along with the tone of your comments in the mailing list thread I find to be filled with hyperbole. I don't think calling out the team publicly with a misleading title was the best way to go about helping the language.
        d2p 12y ago
        I'm sorry if it sounds like I'm being a dick; but I'm incredibly frustrated to have poured so much effort into trying to make Dart a viable option for a rewrite where I work (I've even been working on a Visual Studio extension since all the devs here are primitively .NET devs). To find something so fundamental missing with no reasonable solution (and no information from the Dart team) is frustrating; it's not going to make selling Dart to my colleagues any easier.
        frowaway001 12y ago
        I'm kind of interested why you considered Dart in the first place. Google has such a poor track record in language design, that when I was looking for a compile-to-JavaScript language I didn't even consider Dart.
        icebraining 12y ago
        Just out of curiosity, what is Google's track record in language design? I don't remember any languages coming from them besides Go and Dart.
        d2p 12y ago
        I wrote a blog post some time ago: http://blog.dantup.com/2014/05/web-development-sucks-and-its-not-getting-any-better/ http://blog.dantup.com/2014/05/web-development-sucks-and-its... And while responding to comments, I read a little more about Dart and it started to look quite appealing. I spend too much of my day maintaining and debugging legacy JavaScript written years ago in sub-optimal ways.
    - jnbiche 12y ago
      If he's going to do that, how about everyone here who's a Google employee mention that, too? It shouldn't matter? Well, then it shouldn't matter for d2p, either. Let's argue facts, not personalities.
      - lmm 12y ago
        I'll bite your bullet. I think people who are Google employees should be declaring that.
  - nailer 12y ago
    Ultimately someone will wonder why Dart hasn't taken off since it was released two years ago, and start talking to web developers about what they want out of a future browser-based programming language.
    - WoodenChair 12y ago
      I can see I'm playing Dart apologist today - but to be precise, Dart 1.0 (the first non-beta release) came out approximately 9 months ago, not 2 years ago.
      - nailer 12y ago
        Yep, however Dart was announced (and started getting feedback) 1020 days ago: https://news.ycombinator.com/item?id=3092558 https://news.ycombinator.com/item?id=3092558
  - lmm 12y ago
    Protobuf is static enough. And the claim that everything will be broken or abandoned in 6 months is rather chicken-and-egg; at the moment Dart is a young, relatively obscure language, it doesn't have a mature, reliable library ecosystem. But the only way it's going to get there is if people start using it, using its libraries, writing their own libraries, and figuring out what works and what doesn't. > Doesn't it seem strange that a Google-designed language for the future of the web (that's supposed to make development faster and easier) doesn't handle this (basic) requirement easily? I don't think it's fair to call this a basic requirement. Scala is a 10-year-old language and the state of JSON serialization is still a mess (it's taken the recent macro system to put us anywhere close to sorting it out). Converting between typed and untyped at the boundaries like this is a hard problem, not entirely solved in any language (Java has basically given up and just used reflection and annotations, which is an answer, but not a very pleasant one). I think Dart is entirely right to take it slowly and make it a matter for third-party libraries rather than a core language feature.
    - d2p 12y ago
      I tried to use protobuffers, to find the protobuffer library doesn't work on Windows.
      - lmm 12y ago
        I'm not entirely surprised. Protobuf requires native code, and not many developers care about Windows. It's likely not going to take a lot of work to fix it. But yeah, small, immature language (and not a million miles away from the experience in vanilla JS - I've encountered plenty of e.g. grunt plugins that don't work on Windows either. Even in Ruby there are things that break). I think you're expecting too much from Dart. If you want a rock-solid corporate language, it's not there yet; nor is any language of comparable age. You're going to have to get your hands dirty now and again.
- WoodenChair 12y ago
  Agreed, this is borderline FUD. The main complaint of the thread starter is that Dart doesn't have as good built-in JSON deserialization as C# (which although I haven't used C# in a while, from what he describes is essentially true). However, Dart does have built-in JSON support. See this article: https://www.dartlang.org/articles/json-web-service/ https://www.dartlang.org/articles/json-web-service/ And here's a quote by Alan Knight from the thread on the state of third party libraries: "I'm aware of three options, all already mentioned here, that are at least partly written by the Dart team, if you are looking for extremely simple there is a JSONCodec in dart:convert. If you are looking for something very general that can with minimal configuration (minimal configuration requires mirrors, so it will have overhead) there is the serialization package. If you are looking for high performance but need some configuration then protocol buffers are probably your best bet, and there are certainly things that support using protocol buffers in C#. There are various other options people have written for their specific requirements, as seen elsewhere in this thread."
  - d2p 12y ago
    The built-in stuff you mention deserialises into maps, not Dart classes. This loses all type checking, code-completion, etc. (this is all detailed in the thread ;-))
    - WoodenChair 12y ago
      I read the whole thread, but your title here is misleading: "Google's Dart doesn't support deserialising JSON (or anything) into Dart Types " You mean that it doesn't have support for deserializing into custom Dart types - it does have built-in support for deserializing into Map, List, String, etc...
      - d2p 12y ago
        You're right; "Dart Types" is slightly ambiguous, it wasn't intended that way. It's possible to deserialise into a Map; but not into a type you defined (or even a built-in type that isn't in a small list of types it knows about).
marktangotango 12y ago
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.
- d2p 12y ago
  It does support deserialising into a map, but not a class. One of the selling points of Dart is classes; which can give code-completion, static analysis, etc.. This is all lost if you use maps instead of classes.
  - sigzero 12y ago
    The top comment as well as the answer in the thread explains why.
    - d2p 12y ago
      Not really; that comment is incorrect. For example, in C# there's a JavaScriptSerializer.Deserialize<T>(string) method that does just this.
- jenscow 12y ago
  JSON isn't a feature of JavaScript. It's the other way around.
colanderman 12y ago
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!) 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. 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.
- d2p 12y ago
  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!
  - bad_user 12y ago
    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.
    - d2p 12y ago
      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.
      - bad_user 12y ago
easytiger 12y ago
The stupidity of the question is causing me to have neural pathway executions that are akin to an electoral storm. 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?
- d2p 12y ago
  Many products are > 1m LoC. I never said those 1m LoC are in one file (or even one repository).
  - easytiger 12y ago
    1m LoC are in one file (or even one repository). And so your goal is to rewrite them? What is the point? What about the current codebase has business requirements that need it to be rewritten?
    - d2p 12y ago
      The reason for a rewrite is beyond the scope of Dart supporting sane serialisation. There are many reasons; but here is not an appropriate place to detail them.
TeeWEE 12y ago
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. 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? You should off course try to prevent entangling dependency of a lib into your code base. But thats a basic rule of software engineering. B.t.w, with testing, you can mock away those libraries and still have nice unit tests.
- wolfwyrd 12y ago
  I think the point of the author wasn't that libraries are bad per sé, it's more that why should a library be needed for something that's core to the purpose of the language.
- d2p 12y ago
  There are lots of details about what we're rewriting any why that aren't really relevant to this discussion. I'm (we're) not against 3rd party libraries; but we'd like to minimise our use of them because we're constantly bitten by poor libraries introducing breaking changes or being abandoned. I'm sure anyone that has worked on a huge codebase over a long period of time has been bitten in the same way. We certainly don't want to rely on 3rd party libraries for something so fundamental (and the absence of it from the Dart Team only makes us more concerned).
  - andybak 12y ago
    > poor libraries introducing breaking changes Don't update unless you have to? > being abandoned How is abandoned 3rd party code any worse than code you wrote yourself? In one instance you won't get any updates unless you write them yourself, in the other... 3rd party code is almost always a win - at best you get free code, at the very worst you get to look at some code that you can learn something from.
DCKing 12y ago
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: - Present your complaints as though Dart is missing basic functionality (not in the presence of the presented alternatives). It just misses your specific desired functionality! - Assume your use case is representative for a significant amount of other developers. - Extend your entitlement to the HN front page. 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. As a reference, here's a list of other typed languages that don't support JSON deserialization-to-classes in their core libraries: - Java (Scala, Groovy, Xtend, etc...) - GWT Java - Kotlin (both on JVM and in browser) - Ceylon - C++ - OCaml - Swift - ... 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. [1]: https://code.google.com/p/dart/wiki/Contributing https://code.google.com/p/dart/wiki/Contributing
- d2p 12y ago
  > Present your complaints as though Dart is missing basic functionality In many peoples opinions, it is. Your opinion is no more fact than mine. > Assume your use case is representative for a significant amount of other developers I can assume what I want. I believe it's true. It might not be; but it seems like a pretty basic requirement; and there are many other people in that thread that share the opinion. > Extend your entitlement to the HN front page. I didn't put it there, the people did. > you are very free to make a Dart library that does exactly that That's the whole point - there is no sensible way to implement this from the outside; that's the whole point of my thread. All of the ways of achieving this suck for one reason or another. Doing this well needs better support from the language/Dart tools. > the problem you are complaining about simply isn't as big as you think it is I've still yet to see anyone anywhere post a small code sample showing a Dart class and some simply JSON that works, without a hand-coded mapping from a Map. Is this really what we should be spending our time doing using Google's "new language for the web"?
jdonaldson 12y ago
One thing Haxe does well here is provide structural typing, effectively letting you declare the result of a deserialization process in type form. 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). 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). 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.
- jdonaldson 12y ago
  quick sketch: http://try.haxe.org/#db206 http://try.haxe.org/#db206 I can't show the "using" method directly here since the two classes need to be in separate files... but I'm giving an example of what it would look like.

36 points by d2p 12y ago

clubhi 12y ago

When I was a kid you used to serialize to JSON.

deleted 12y ago

[deleted]

kyrra 12y ago

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.

d2p 12y ago
Did you read about any of the suggested options? They all basically suck; requiring tons of boilerplate; are not-static formats (making it difficult to implement "the other side"); poor performance; and mostly implemented by third parties so they'll likely be broken or abandoned in 6 months. Doesn't it seem strange that a Google-designed language for the future of the web (that's supposed to make development faster and easier) doesn't handle this (basic) requirement easily?
- WoodenChair 12y ago
  I think it would be respectful if you mentioned that you are the starter of the thread on the mailing list in the first place...
  - d2p 12y ago
    Apologies; it's been so long since I signed up, I didn't realise my username was quite so cryptic. The thread is indeed mine, and I posted it here in the hope that it might be seen by someone on the Dart Team, as there seems to have been no response from Google on this hole :(
    - WoodenChair 12y ago
      I can assure you that the Dart team reads the mailing list and has almost certainly seen your thread there. I appreciate (and can see) that you honestly want to help Dart succeed, but the title of this thread along with the tone of your comments in the mailing list thread I find to be filled with hyperbole. I don't think calling out the team publicly with a misleading title was the best way to go about helping the language.
      - d2p 12y ago
        I'm sorry if it sounds like I'm being a dick; but I'm incredibly frustrated to have poured so much effort into trying to make Dart a viable option for a rewrite where I work (I've even been working on a Visual Studio extension since all the devs here are primitively .NET devs). To find something so fundamental missing with no reasonable solution (and no information from the Dart team) is frustrating; it's not going to make selling Dart to my colleagues any easier.
        frowaway001 12y ago
        I'm kind of interested why you considered Dart in the first place. Google has such a poor track record in language design, that when I was looking for a compile-to-JavaScript language I didn't even consider Dart.
        icebraining 12y ago
        Just out of curiosity, what is Google's track record in language design? I don't remember any languages coming from them besides Go and Dart.
        d2p 12y ago
        I wrote a blog post some time ago: http://blog.dantup.com/2014/05/web-development-sucks-and-its-not-getting-any-better/ http://blog.dantup.com/2014/05/web-development-sucks-and-its... And while responding to comments, I read a little more about Dart and it started to look quite appealing. I spend too much of my day maintaining and debugging legacy JavaScript written years ago in sub-optimal ways.
  - jnbiche 12y ago
    If he's going to do that, how about everyone here who's a Google employee mention that, too? It shouldn't matter? Well, then it shouldn't matter for d2p, either. Let's argue facts, not personalities.
    - lmm 12y ago
      I'll bite your bullet. I think people who are Google employees should be declaring that.
- nailer 12y ago
  Ultimately someone will wonder why Dart hasn't taken off since it was released two years ago, and start talking to web developers about what they want out of a future browser-based programming language.
  - WoodenChair 12y ago
    I can see I'm playing Dart apologist today - but to be precise, Dart 1.0 (the first non-beta release) came out approximately 9 months ago, not 2 years ago.
    - nailer 12y ago
      Yep, however Dart was announced (and started getting feedback) 1020 days ago: https://news.ycombinator.com/item?id=3092558 https://news.ycombinator.com/item?id=3092558
- lmm 12y ago
  Protobuf is static enough. And the claim that everything will be broken or abandoned in 6 months is rather chicken-and-egg; at the moment Dart is a young, relatively obscure language, it doesn't have a mature, reliable library ecosystem. But the only way it's going to get there is if people start using it, using its libraries, writing their own libraries, and figuring out what works and what doesn't. > Doesn't it seem strange that a Google-designed language for the future of the web (that's supposed to make development faster and easier) doesn't handle this (basic) requirement easily? I don't think it's fair to call this a basic requirement. Scala is a 10-year-old language and the state of JSON serialization is still a mess (it's taken the recent macro system to put us anywhere close to sorting it out). Converting between typed and untyped at the boundaries like this is a hard problem, not entirely solved in any language (Java has basically given up and just used reflection and annotations, which is an answer, but not a very pleasant one). I think Dart is entirely right to take it slowly and make it a matter for third-party libraries rather than a core language feature.
  - d2p 12y ago
    I tried to use protobuffers, to find the protobuffer library doesn't work on Windows.
    - lmm 12y ago
      I'm not entirely surprised. Protobuf requires native code, and not many developers care about Windows. It's likely not going to take a lot of work to fix it. But yeah, small, immature language (and not a million miles away from the experience in vanilla JS - I've encountered plenty of e.g. grunt plugins that don't work on Windows either. Even in Ruby there are things that break). I think you're expecting too much from Dart. If you want a rock-solid corporate language, it's not there yet; nor is any language of comparable age. You're going to have to get your hands dirty now and again.
WoodenChair 12y ago
Agreed, this is borderline FUD. The main complaint of the thread starter is that Dart doesn't have as good built-in JSON deserialization as C# (which although I haven't used C# in a while, from what he describes is essentially true). However, Dart does have built-in JSON support. See this article: https://www.dartlang.org/articles/json-web-service/ https://www.dartlang.org/articles/json-web-service/ And here's a quote by Alan Knight from the thread on the state of third party libraries: "I'm aware of three options, all already mentioned here, that are at least partly written by the Dart team, if you are looking for extremely simple there is a JSONCodec in dart:convert. If you are looking for something very general that can with minimal configuration (minimal configuration requires mirrors, so it will have overhead) there is the serialization package. If you are looking for high performance but need some configuration then protocol buffers are probably your best bet, and there are certainly things that support using protocol buffers in C#. There are various other options people have written for their specific requirements, as seen elsewhere in this thread."
- d2p 12y ago
  The built-in stuff you mention deserialises into maps, not Dart classes. This loses all type checking, code-completion, etc. (this is all detailed in the thread ;-))
  - WoodenChair 12y ago
    I read the whole thread, but your title here is misleading: "Google's Dart doesn't support deserialising JSON (or anything) into Dart Types " You mean that it doesn't have support for deserializing into custom Dart types - it does have built-in support for deserializing into Map, List, String, etc...
    - d2p 12y ago
      You're right; "Dart Types" is slightly ambiguous, it wasn't intended that way. It's possible to deserialise into a Map; but not into a type you defined (or even a built-in type that isn't in a small list of types it knows about).

marktangotango 12y ago

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.

d2p 12y ago
It does support deserialising into a map, but not a class. One of the selling points of Dart is classes; which can give code-completion, static analysis, etc.. This is all lost if you use maps instead of classes.
- sigzero 12y ago
  The top comment as well as the answer in the thread explains why.
  - d2p 12y ago
    Not really; that comment is incorrect. For example, in C# there's a JavaScriptSerializer.Deserialize<T>(string) method that does just this.
jenscow 12y ago
JSON isn't a feature of JavaScript. It's the other way around.

colanderman 12y ago

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!) 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. 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.

d2p 12y ago
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!
- bad_user 12y ago
  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.
  - d2p 12y ago
    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.
    - bad_user 12y ago

easytiger 12y ago

The stupidity of the question is causing me to have neural pathway executions that are akin to an electoral storm. 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?

d2p 12y ago
Many products are > 1m LoC. I never said those 1m LoC are in one file (or even one repository).
- easytiger 12y ago
  1m LoC are in one file (or even one repository). And so your goal is to rewrite them? What is the point? What about the current codebase has business requirements that need it to be rewritten?
  - d2p 12y ago
    The reason for a rewrite is beyond the scope of Dart supporting sane serialisation. There are many reasons; but here is not an appropriate place to detail them.

TeeWEE 12y ago

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. 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? You should off course try to prevent entangling dependency of a lib into your code base. But thats a basic rule of software engineering. B.t.w, with testing, you can mock away those libraries and still have nice unit tests.

wolfwyrd 12y ago
I think the point of the author wasn't that libraries are bad per sé, it's more that why should a library be needed for something that's core to the purpose of the language.
d2p 12y ago
There are lots of details about what we're rewriting any why that aren't really relevant to this discussion. I'm (we're) not against 3rd party libraries; but we'd like to minimise our use of them because we're constantly bitten by poor libraries introducing breaking changes or being abandoned. I'm sure anyone that has worked on a huge codebase over a long period of time has been bitten in the same way. We certainly don't want to rely on 3rd party libraries for something so fundamental (and the absence of it from the Dart Team only makes us more concerned).
- andybak 12y ago
  > poor libraries introducing breaking changes Don't update unless you have to? > being abandoned How is abandoned 3rd party code any worse than code you wrote yourself? In one instance you won't get any updates unless you write them yourself, in the other... 3rd party code is almost always a win - at best you get free code, at the very worst you get to look at some code that you can learn something from.

DCKing 12y ago

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: - Present your complaints as though Dart is missing basic functionality (not in the presence of the presented alternatives). It just misses your specific desired functionality! - Assume your use case is representative for a significant amount of other developers. - Extend your entitlement to the HN front page. 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. As a reference, here's a list of other typed languages that don't support JSON deserialization-to-classes in their core libraries: - Java (Scala, Groovy, Xtend, etc...) - GWT Java - Kotlin (both on JVM and in browser) - Ceylon - C++ - OCaml - Swift - ... 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. [1]: https://code.google.com/p/dart/wiki/Contributing https://code.google.com/p/dart/wiki/Contributing

d2p 12y ago
> Present your complaints as though Dart is missing basic functionality In many peoples opinions, it is. Your opinion is no more fact than mine. > Assume your use case is representative for a significant amount of other developers I can assume what I want. I believe it's true. It might not be; but it seems like a pretty basic requirement; and there are many other people in that thread that share the opinion. > Extend your entitlement to the HN front page. I didn't put it there, the people did. > you are very free to make a Dart library that does exactly that That's the whole point - there is no sensible way to implement this from the outside; that's the whole point of my thread. All of the ways of achieving this suck for one reason or another. Doing this well needs better support from the language/Dart tools. > the problem you are complaining about simply isn't as big as you think it is I've still yet to see anyone anywhere post a small code sample showing a Dart class and some simply JSON that works, without a hand-coded mapping from a Map. Is this really what we should be spending our time doing using Google's "new language for the web"?

jdonaldson 12y ago

One thing Haxe does well here is provide structural typing, effectively letting you declare the result of a deserialization process in type form. 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). 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). 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.

jdonaldson 12y ago
quick sketch: http://try.haxe.org/#db206 http://try.haxe.org/#db206 I can't show the "using" method directly here since the two classes need to be in separate files... but I'm giving an example of what it would look like.