3 ms·

>Look at how much code Jackson uses for their core serialization Is the problem complexity or bandwidth? You already have "dart:convert" in the browser, and h

>Look at how much code Jackson uses for their core serialization Is the problem complexity or bandwidth? You already have "dart:convert" in the browser, and has JSON, ASCII and you can even add your own formats to it, and it runs in the browser, now, what I can undertands is that you'll need to add mirrors as a requirement and mirros can be big, but again, don't you already need reflection for polymer? It is really that a problem to instead of mapping JSON to a map have the chance to map to an Object<T>? I don't think it is a problem of complexity, but a problem of apathy, or "you don't really need that anyway" issue, and I hate when some one tries to tell me what I need and what I don't.

spankalee 12y ago
Apathy? We created the JSON decoder in dart:convert, the serialization package, the protobuf compiler, and one of the JSON Schema based generators. Our largest internal customer created Streamy. If you have an easy magical solution that fits more use cases that what we're already using in real production code, and also aren't affected by too much apathy, then we gladly accept contributions to the core SDK, and you can of course always publish your own package. I'd be very interested in seeing what a team less apathetic that the ones that produced five serialization packages comes up with.
- adrianlmm 12y ago
  >We created the JSON decoder in dart:convert, the serialization package, the protobuf compiler, and one of the JSON Schema based generators Great, then you already have 90% of the job done then. >If you have an easy magical solution that fits more use cases that what we're already using in real production code What are bug reports for? >I'd be very interested in seeing what a team less apathetic that the ones that produced five serialization packages comes up with. I don't know, but the 5 bugs I've submitted to Dart haven't been fixed yet, I submitted those almost 2 years ago all marked in the core as medium, so, you tell me, what conclusion should I make?
  - spankalee 12y ago
    >>If you have an easy magical solution that fits more use cases that what we're already using in real production code >What are bug reports for? If you have a bug report with the description of the behavior you want, then that's at least a start. My point is that I'm claiming there isn't an obvious one-size-fits-all solution, and that we've created several serialization packages, clearly demonstrating that we're not apathetic regarding serialization. To imply so is frankly insulting. >I don't know, but the 5 bugs I've submitted to Dart haven't been fixed yet, I submitted those almost 2 years ago all marked in the core as medium, so, you tell me, what conclusion should I make? That all projects of this magnitude have many open bugs? We have almost 4000 open issues out of 20,000 all time. Yes, many of those open issues are old, it's much easier to open them than close them, and some answers just aren't clear. I assume these are your issues: https://code.google.com/p/dart/issues/list?q=adrian https://code.google.com/p/dart/issues/list?q=adrian First, it's clear you've been using Dart from the start and that you've filed good reports, so thank you very much. There are 3 open out of 13 total. The double.round() one is good, IMO. I don't know why it hasn't been addressed, other than the sheer volume of bugs we have. I would recommend that the squeaky wheel gets the oil. Sorry, but it's just reality with a large project and team. The other two I don't see clear consensus on, and the comments seem to indicate that the current behavior is intended. I personally agree with you on the Dart parse issue, but think that we shouldn't special case Completer, but instead work on union types.
    - adrianlmm 12y ago
      I know that I'm not working in the next super text-editor, or in the next super-game, but I'm using Dart in a enterprice enviroment where numbers do matter, so If I see something as trivial as double.round not having what I need I really get demotivated, so, I'm sorry for getting emotional. I'm using .NET in the server and if there is something MS does right is to listen to their enterprice customers, even if those customers do boring stuff like capturing forms and displaying numbers, but hey, those are important stuff for enterprices, same with the DateTime.parse, numbers and dates is an every day issue here, and is very important, and I'd like to see Dart also focusing in this type of market, we are alot. The Completer bug I is also key for scalable projects, we, the ones using Dart, assume that the type safety part of Dart is reliable to do our work. Anyway, I'm, glad at least one Dart developer is here to listen.
DCKing 12y ago
> Is the problem complexity or bandwidth? Bandwidth is a prohibitive technical problem in this case. Complexity of such an API is a solvable problem in principle, but it will only get solved if a practical API can be made. My argument is that such an API cannot be made, because it will be too large, too fragile, or both. > what I can undertands is that you'll need to add mirrors as a requirement and mirros can be big, but again, don't you already need reflection for polymer? I don't know if Polymer.dart depends on mirrors, but it's irrelevant as neither Polymer or Mirrors are part of the core library. > It is really that a problem to instead of mapping JSON to a map have the chance to map to an Object<T>? Yes, because because reliably instantiating an arbitrary object with all data in the right place during runtime is just quite a hard problem in a static language. Available (de)serialization libraries demonstrate that. > "I don't think it is a problem of complexity, but a problem of apathy, or "you don't really need that anyway" issue," My argument is that it's an issue of downsides not being worth the benefits. If this was possible in any practical way at all, I think it would be in there. > and I hate when some one tries to tell me what I need and what I don't. That's your problem, not a valid reason to criticise the Dart developers. Nobody is denying you anything. Your assumption that this is possible in the Dart core library in a practical sense is very likely simply wrong.
- adrianlmm 12y ago
  > My argument is that such an API cannot be made, because it will be too large, too fragile, or both With that logic, why does Dart even has futures? I bet those are more complex and use more code, and yet, Dart have them, so I don't think it is about "being large and fragile". >I don't know if Polymer.dart depends on mirrors, but it's irrelevant as neither Polymer or Mirrors are part of the core library Since Dart developers are obsessed with Polymeter I wouldn't say is not relevant, and if they would have to make the JSON to Object<T> serialization in another library and not in the core then so be it, nobody is asking them to put it in the core. > Yes, because because reliably instantiating an arbitrary object with all data in the right place during runtime is just quite a hard problem in a static language They already have 90% of te job done, they have the JSON parser, they have mirrors, btw, JSON is a very simple format in the case you don't know, they already have mirrors to instantiate objects at runtime, they instantiate Maps, why can't they instantiate Objects with mirrors? is not logical, the other reflections libraries seem to work pretty well so, is not an excuse. > My argument is that it's an issue of downsides not being worth the benefits For who? maybe not for you, but for others it would. > That's your problem, not a valid reason to criticise the Dart developers Dart developers are humans and fallible, so they are not supergods or something, and Im not asking to put this in the core.

spankalee 12y ago

Apathy? We created the JSON decoder in dart:convert, the serialization package, the protobuf compiler, and one of the JSON Schema based generators. Our largest internal customer created Streamy. If you have an easy magical solution that fits more use cases that what we're already using in real production code, and also aren't affected by too much apathy, then we gladly accept contributions to the core SDK, and you can of course always publish your own package. I'd be very interested in seeing what a team less apathetic that the ones that produced five serialization packages comes up with.

adrianlmm 12y ago
>We created the JSON decoder in dart:convert, the serialization package, the protobuf compiler, and one of the JSON Schema based generators Great, then you already have 90% of the job done then. >If you have an easy magical solution that fits more use cases that what we're already using in real production code What are bug reports for? >I'd be very interested in seeing what a team less apathetic that the ones that produced five serialization packages comes up with. I don't know, but the 5 bugs I've submitted to Dart haven't been fixed yet, I submitted those almost 2 years ago all marked in the core as medium, so, you tell me, what conclusion should I make?
- spankalee 12y ago
  >>If you have an easy magical solution that fits more use cases that what we're already using in real production code >What are bug reports for? If you have a bug report with the description of the behavior you want, then that's at least a start. My point is that I'm claiming there isn't an obvious one-size-fits-all solution, and that we've created several serialization packages, clearly demonstrating that we're not apathetic regarding serialization. To imply so is frankly insulting. >I don't know, but the 5 bugs I've submitted to Dart haven't been fixed yet, I submitted those almost 2 years ago all marked in the core as medium, so, you tell me, what conclusion should I make? That all projects of this magnitude have many open bugs? We have almost 4000 open issues out of 20,000 all time. Yes, many of those open issues are old, it's much easier to open them than close them, and some answers just aren't clear. I assume these are your issues: https://code.google.com/p/dart/issues/list?q=adrian https://code.google.com/p/dart/issues/list?q=adrian First, it's clear you've been using Dart from the start and that you've filed good reports, so thank you very much. There are 3 open out of 13 total. The double.round() one is good, IMO. I don't know why it hasn't been addressed, other than the sheer volume of bugs we have. I would recommend that the squeaky wheel gets the oil. Sorry, but it's just reality with a large project and team. The other two I don't see clear consensus on, and the comments seem to indicate that the current behavior is intended. I personally agree with you on the Dart parse issue, but think that we shouldn't special case Completer, but instead work on union types.
  - adrianlmm 12y ago
    I know that I'm not working in the next super text-editor, or in the next super-game, but I'm using Dart in a enterprice enviroment where numbers do matter, so If I see something as trivial as double.round not having what I need I really get demotivated, so, I'm sorry for getting emotional. I'm using .NET in the server and if there is something MS does right is to listen to their enterprice customers, even if those customers do boring stuff like capturing forms and displaying numbers, but hey, those are important stuff for enterprices, same with the DateTime.parse, numbers and dates is an every day issue here, and is very important, and I'd like to see Dart also focusing in this type of market, we are alot. The Completer bug I is also key for scalable projects, we, the ones using Dart, assume that the type safety part of Dart is reliable to do our work. Anyway, I'm, glad at least one Dart developer is here to listen.

DCKing 12y ago

> Is the problem complexity or bandwidth? Bandwidth is a prohibitive technical problem in this case. Complexity of such an API is a solvable problem in principle, but it will only get solved if a practical API can be made. My argument is that such an API cannot be made, because it will be too large, too fragile, or both. > what I can undertands is that you'll need to add mirrors as a requirement and mirros can be big, but again, don't you already need reflection for polymer? I don't know if Polymer.dart depends on mirrors, but it's irrelevant as neither Polymer or Mirrors are part of the core library. > It is really that a problem to instead of mapping JSON to a map have the chance to map to an Object<T>? Yes, because because reliably instantiating an arbitrary object with all data in the right place during runtime is just quite a hard problem in a static language. Available (de)serialization libraries demonstrate that. > "I don't think it is a problem of complexity, but a problem of apathy, or "you don't really need that anyway" issue," My argument is that it's an issue of downsides not being worth the benefits. If this was possible in any practical way at all, I think it would be in there. > and I hate when some one tries to tell me what I need and what I don't. That's your problem, not a valid reason to criticise the Dart developers. Nobody is denying you anything. Your assumption that this is possible in the Dart core library in a practical sense is very likely simply wrong.

adrianlmm 12y ago
> My argument is that such an API cannot be made, because it will be too large, too fragile, or both With that logic, why does Dart even has futures? I bet those are more complex and use more code, and yet, Dart have them, so I don't think it is about "being large and fragile". >I don't know if Polymer.dart depends on mirrors, but it's irrelevant as neither Polymer or Mirrors are part of the core library Since Dart developers are obsessed with Polymeter I wouldn't say is not relevant, and if they would have to make the JSON to Object<T> serialization in another library and not in the core then so be it, nobody is asking them to put it in the core. > Yes, because because reliably instantiating an arbitrary object with all data in the right place during runtime is just quite a hard problem in a static language They already have 90% of te job done, they have the JSON parser, they have mirrors, btw, JSON is a very simple format in the case you don't know, they already have mirrors to instantiate objects at runtime, they instantiate Maps, why can't they instantiate Objects with mirrors? is not logical, the other reflections libraries seem to work pretty well so, is not an excuse. > My argument is that it's an issue of downsides not being worth the benefits For who? maybe not for you, but for others it would. > That's your problem, not a valid reason to criticise the Dart developers Dart developers are humans and fallible, so they are not supergods or something, and Im not asking to put this in the core.