3 ms·

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 pr

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?
- adrianlmm 12y ago
  >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.
- deleted 12y ago
  [deleted]

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?

adrianlmm 12y ago
>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.
deleted 12y ago
[deleted]