4 ms·

>Could that be explained because of not used to type safe languages? Is not about type safe, Dart can be used as both, a type safe lenguage and as a dynamic le

>Could that be explained because of not used to type safe languages? Is not about type safe, Dart can be used as both, a type safe lenguage and as a dynamic lenguage, demanding to cover a certain part of of what a type safe language has it is reasonable, now, if the package was to big for Dart designers they should have made Dart a dynamic language only. > This assertion is simply false. Is not that false, anyone can do a JSON to bject parser, the problem I see is that they would need to include mirrors as default to give such functonality, but when exported to JavaScript mirrors would make the exported file to be huge, so I see this as a way to mitigate the desing problems Dart it self has. As I said, they need to put first in the user shoes and see what is convenient to them and then work in the desing, but I get the impression that they desingned Dart to be fast, it doesn't matter if some desitions affect the developers, the priority is make it fast and not handy for developers.

DCKing 12y ago
> Is not about type safe, Dart can be used as both, a type safe lenguage and as a dynamic lenguage, demanding to cover a certain part of of what a type safe language has it is reasonable, now, if the package was to big for Dart designers they should have made Dart a dynamic language only. If the goal is not to make it type safe, then there is really no objection to just use the built-in Map+List JSON parser, is there? > I see this as a way to mitigate the desing problems Dart it self has. How could a language a language possess both classes and not spend a lot of complexity trying to shoehorn JSON objects to fill the data in those classes? This is not a problem of Dart, this is a problem of class-based object orientation. It baffles me that people expect it to arbitrarily map JSON to those classes when the associated complexity is well-known.
- adrianlmm 12y ago
  >If the goal is not to make it type safe, then there is really no objection to just use the built-in Map+List JSON parser, is there? A Map is not type safe, at least, not the default result of a JSON.decode in Dart, actually, the result is a dynamic Map. I don't know what your point is. >This is not a problem of Dart, this is a problem of class-based object orientation It is not a problem, it is a must have. The associated "complexity" was overcome many years ago with Generics (or templates), Dart has this, so, there is no excuse.
  - DCKing 12y ago
    > A Map is not type safe, at least, not the default result of a JSON.decode in Dart, actually, the result is a dynamic Map. I don't know what your point is. A dynamic type does not give you type safety, and neither does a dynamic Map. A dynamic type might give you a little more type safety than a map, but invalid member access would give you as much headache in both situations. So why even bother dragging in so much complexity for this when you can just write your own code? > It is not a problem, it is a must have. You say that as if it's a fact. Have I not put enough on the table to demonstrate that what you're saying is 1) an opinion 2) a minority opinion 3) is ignorant of the associated complexities 4) demonstrably not necessary for web applications? > The associated "complexity" was overcome many years ago with Generics (or templates), Dart has this, so, there is no excuse. Please explain how generics helps in overcoming this complexity. I'm genuinely interested.
    - adrianlmm 12y ago
      Please before I can answer you, tell me what is that mythical "complexity" in doing it first, because, we haven't stablished what is it, what is actually the problem? >is ignorant of the associated complexities Tell me what complexities?
      - DCKing 12y ago
        Look at how much code Jackson uses for their core serialization: https://github.com/FasterXML/jackson-core https://github.com/FasterXML/jackson-core . This is a (the?) .NET library for the same: https://github.com/JamesNK/Newtonsoft.Json/tree/master/Src/Newtonsoft.Json https://github.com/JamesNK/Newtonsoft.Json/tree/master/Src/N... That's a lot of code, don't you think? Quite a bit of work to write it. Quite a bit of edge cases to cover. It's fine to include this in your compiled distributed server or client application. But it's quite a problem if it needs to be loaded in the browser. You could argue that a simpler, less complete implementation is in order. But what language developer would want to include an API that is known to be incomplete and therefore fragile? This seems to be a job for an external library. I'm still trying to find another statically typed class based compile-to-JS language that does deserialization like proposed, but I still can't seem to find it. Could it be unwillingness like you suggested? Seems unlikely to me as it does seem quite useful for some quick and dirty applications at the very least. Or maybe could it be that satisfactory implementations could not be made?
- d2p 12y ago
  > It baffles me that people expect it to arbitrarily map JSON to those classes when the associated complexity is well-known That's because you're adding complexity that nobody is asking for. Deserialising JSON onto a simple PODO with no inheritance, no mis-matching of properrty names, etc., is a pretty trivial requirement. The impelementation complexity is being used as an excuse not to meet a really basic need of a web app. Please tell me - how am I supposed to get data from a server, into a data structure that will give me code-completion and type checking? Other languages with types do this fine; why should I hand-code a load of mapping of basic values in Dart?
  - dragonwriter 12y ago
    > Please tell me - how am I supposed to get data from a server, into a data structure that will give me code-completion and type checking? Write a fromMap constructor. > Other languages with types do this fine; why should I hand-code a load of mapping of basic values in Dart? For one thing, to reduce the degree of coupling between your client code and the interchange format. With a fromMap constructor, anything interchange format that can deserialize into a generic map-of-strings-and-lists-of-strings format can be used (and different external JS structures can be supported, as well, with a simple Map-to-Map converter.) Automagic mapping that relies on matching field names between objects and interchange formats results in tight coupling between client and interchange format.
  - deleted 12y ago
    [deleted]
  - DCKing 12y ago
    > Deserialising JSON onto a simple PODO with no inheritance, no mis-matching of properrty names, etc., is a pretty trivial requirement. This is not serializing into a PODO. This is serializing into a simple struct. Dart does not have simple structs, so you get no deserialization of simple structs. Imagine that you write a core library function that does what you want. It cannot map arbitrary classes, but only a subset of classes that adheres to a "simple structure". The developers would then have to tell you which classes you can use it on, and which classes you can't. It would give you runtime errors when you happen to include inheritance somewhere in your project. It's an unmaintainable situation, and most safety of static checking would be gone. Not just in your project, but every project using that feature. Think of the developers' perspective. Why would they want to include such a fragile feature in the first place? You could argue that Dart needs a "struct"-like construct just to support deserialization. Still the problems remain that that still has all the fragility problems of reflection. Good luck with convincing the developers about adding a language feature for that. They have already shown to not be receptive to that idea [1][2]. You are free to hack your way around typesafety, but you cannot make this a problem of the developers. A type safe language simply brings you inconvenience when you're trying to shoehorn dynamic data in static structure definitions. This is not the Dart developers' problem: increased type safety is their goal. > Please tell me - how am I supposed to get data from a server into a data structure that will give me code-completion and type checking? You either write your own code to do this or don't do this at all and just use the data in another shape. You can keep repeating this point all day long; you won't demonstrate why it is anything more than "nice to have", let alone that it's a "necessity". > Other languages with types do this fine. AFAIK only .NET-based languages and Go do this out of the box. Both can include this out-of-the-box because they are server oriented languages and can include all the complexity they want. Those languages don't care for the binary size of their applications as much as Dart applications. [1]: https://groups.google.com/a/dartlang.org/forum/#!topic/misc/obmjDJJZq8A https://groups.google.com/a/dartlang.org/forum/#!topic/misc/... [2]: https://code.google.com/p/dart/issues/detail?id=10374 https://code.google.com/p/dart/issues/detail?id=10374

DCKing 12y ago

> Is not about type safe, Dart can be used as both, a type safe lenguage and as a dynamic lenguage, demanding to cover a certain part of of what a type safe language has it is reasonable, now, if the package was to big for Dart designers they should have made Dart a dynamic language only. If the goal is not to make it type safe, then there is really no objection to just use the built-in Map+List JSON parser, is there? > I see this as a way to mitigate the desing problems Dart it self has. How could a language a language possess both classes and not spend a lot of complexity trying to shoehorn JSON objects to fill the data in those classes? This is not a problem of Dart, this is a problem of class-based object orientation. It baffles me that people expect it to arbitrarily map JSON to those classes when the associated complexity is well-known.

adrianlmm 12y ago
>If the goal is not to make it type safe, then there is really no objection to just use the built-in Map+List JSON parser, is there? A Map is not type safe, at least, not the default result of a JSON.decode in Dart, actually, the result is a dynamic Map. I don't know what your point is. >This is not a problem of Dart, this is a problem of class-based object orientation It is not a problem, it is a must have. The associated "complexity" was overcome many years ago with Generics (or templates), Dart has this, so, there is no excuse.
- DCKing 12y ago
  > A Map is not type safe, at least, not the default result of a JSON.decode in Dart, actually, the result is a dynamic Map. I don't know what your point is. A dynamic type does not give you type safety, and neither does a dynamic Map. A dynamic type might give you a little more type safety than a map, but invalid member access would give you as much headache in both situations. So why even bother dragging in so much complexity for this when you can just write your own code? > It is not a problem, it is a must have. You say that as if it's a fact. Have I not put enough on the table to demonstrate that what you're saying is 1) an opinion 2) a minority opinion 3) is ignorant of the associated complexities 4) demonstrably not necessary for web applications? > The associated "complexity" was overcome many years ago with Generics (or templates), Dart has this, so, there is no excuse. Please explain how generics helps in overcoming this complexity. I'm genuinely interested.
  - adrianlmm 12y ago
    Please before I can answer you, tell me what is that mythical "complexity" in doing it first, because, we haven't stablished what is it, what is actually the problem? >is ignorant of the associated complexities Tell me what complexities?
    - DCKing 12y ago
      Look at how much code Jackson uses for their core serialization: https://github.com/FasterXML/jackson-core https://github.com/FasterXML/jackson-core . This is a (the?) .NET library for the same: https://github.com/JamesNK/Newtonsoft.Json/tree/master/Src/Newtonsoft.Json https://github.com/JamesNK/Newtonsoft.Json/tree/master/Src/N... That's a lot of code, don't you think? Quite a bit of work to write it. Quite a bit of edge cases to cover. It's fine to include this in your compiled distributed server or client application. But it's quite a problem if it needs to be loaded in the browser. You could argue that a simpler, less complete implementation is in order. But what language developer would want to include an API that is known to be incomplete and therefore fragile? This seems to be a job for an external library. I'm still trying to find another statically typed class based compile-to-JS language that does deserialization like proposed, but I still can't seem to find it. Could it be unwillingness like you suggested? Seems unlikely to me as it does seem quite useful for some quick and dirty applications at the very least. Or maybe could it be that satisfactory implementations could not be made?
d2p 12y ago
> It baffles me that people expect it to arbitrarily map JSON to those classes when the associated complexity is well-known That's because you're adding complexity that nobody is asking for. Deserialising JSON onto a simple PODO with no inheritance, no mis-matching of properrty names, etc., is a pretty trivial requirement. The impelementation complexity is being used as an excuse not to meet a really basic need of a web app. Please tell me - how am I supposed to get data from a server, into a data structure that will give me code-completion and type checking? Other languages with types do this fine; why should I hand-code a load of mapping of basic values in Dart?
- dragonwriter 12y ago
  > Please tell me - how am I supposed to get data from a server, into a data structure that will give me code-completion and type checking? Write a fromMap constructor. > Other languages with types do this fine; why should I hand-code a load of mapping of basic values in Dart? For one thing, to reduce the degree of coupling between your client code and the interchange format. With a fromMap constructor, anything interchange format that can deserialize into a generic map-of-strings-and-lists-of-strings format can be used (and different external JS structures can be supported, as well, with a simple Map-to-Map converter.) Automagic mapping that relies on matching field names between objects and interchange formats results in tight coupling between client and interchange format.
- deleted 12y ago
  [deleted]
- DCKing 12y ago
  > Deserialising JSON onto a simple PODO with no inheritance, no mis-matching of properrty names, etc., is a pretty trivial requirement. This is not serializing into a PODO. This is serializing into a simple struct. Dart does not have simple structs, so you get no deserialization of simple structs. Imagine that you write a core library function that does what you want. It cannot map arbitrary classes, but only a subset of classes that adheres to a "simple structure". The developers would then have to tell you which classes you can use it on, and which classes you can't. It would give you runtime errors when you happen to include inheritance somewhere in your project. It's an unmaintainable situation, and most safety of static checking would be gone. Not just in your project, but every project using that feature. Think of the developers' perspective. Why would they want to include such a fragile feature in the first place? You could argue that Dart needs a "struct"-like construct just to support deserialization. Still the problems remain that that still has all the fragility problems of reflection. Good luck with convincing the developers about adding a language feature for that. They have already shown to not be receptive to that idea [1][2]. You are free to hack your way around typesafety, but you cannot make this a problem of the developers. A type safe language simply brings you inconvenience when you're trying to shoehorn dynamic data in static structure definitions. This is not the Dart developers' problem: increased type safety is their goal. > Please tell me - how am I supposed to get data from a server into a data structure that will give me code-completion and type checking? You either write your own code to do this or don't do this at all and just use the data in another shape. You can keep repeating this point all day long; you won't demonstrate why it is anything more than "nice to have", let alone that it's a "necessity". > Other languages with types do this fine. AFAIK only .NET-based languages and Go do this out of the box. Both can include this out-of-the-box because they are server oriented languages and can include all the complexity they want. Those languages don't care for the binary size of their applications as much as Dart applications. [1]: https://groups.google.com/a/dartlang.org/forum/#!topic/misc/obmjDJJZq8A https://groups.google.com/a/dartlang.org/forum/#!topic/misc/... [2]: https://code.google.com/p/dart/issues/detail?id=10374 https://code.google.com/p/dart/issues/detail?id=10374