Google's Dart doesn't support deserialising JSON (or anything) into Dart Types
groups.google.com
groups.google.com
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?
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.
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.
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.
However, it doesn't change that the complexity being used as an excuse is not being requested. There are many things people would want to do with their deserialisation, and nobody is asking the Dart Team to provide them all. What is really basic, however, is deserialising data into a flat PODO so that we can take advantage of code-completion and static analysis on our code; isolating the mapping problem to a single point.
It shouldn't matter?
Well, then it shouldn't matter for d2p, either. Let's argue facts, not personalities.
> 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.
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.
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."
(this is all detailed in the thread ;-))
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...
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.
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!
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.
I'm against super complex things, but things going into a standard library should be general enough for 80% of the use-cases in the wild (and no, I don't agree with you here), otherwise it's very hard to make changes in the standard library later, therefore instead of pushing for something half-baked, I would rather wait for third-parties to build such a library.
Scala for example has a shitty JSON parser in the standard library that nowadays nobody uses because it is limited and because third-party libraries are better. I suspect, from what you're telling me, that C#'s standard parser is in the same league.
But "99%" of developers just need serialisation, which is supported. You (and myself) want more than that.
Why are you worried about type-safety? JSON itself only supports object, array, string, number, true/false, and null, so type safety isn't even an issue because invalid JSON will fail to parse. If you're talking about taking a string and regexing it into an address or whatever, then yeah: you should be writing that code yourself.
Because that's one of the huge selling points of Dart?!
If you're writing a client application, you probably have data structures. Some of those data structures you need to send to the server (or receive). When you write code that interacts with those structures, you want code-completion; static analysis, etc.; that's kinda the point of Dart's typing!
Having to choose your serialization strategy is not a bad thing. At the very least, Dart's JSON support is very similar to JavaScript already, and there are several packages that do serialization in different ways.
> in Dart ... Decoding JSON will get you Maps and Lists
What you should typically do in static languages without reflection (C++ etc) is specify a mapping between the implicit JSON schema and your existing class definitions using a set of traits. Boost.Fusion for C++, for example, is one way to map an object to an arbitrary sequence you can utilise for serialization.
Code generation approaches, like out of the box generation from 'Protocol Buffers', is ugly and limited anyway, since you're then forced wrap or abstract away the generated code, or put up with its style and limitations. If your JSON schema changes in the future, for example, you will have to change your code all over the place rather than just the serialize/deserialize routines.
- 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.
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"?
You've got that right. My problem is that you framed your thread title and general discussion so that it implies that Dart is lacking in JSON support. It's not; Dart's JSON support is better than or on par with almost all other languages out there (including JavaScript). The problem for you is that it lacks a certain style of JSON support, which I think you'll find a hard time arguing why it's basic functionality.
> I didn't put it there, the people did.
Come on. You submitted it, and did not want it on the front page?
> 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.
Yes there is. Dart's reflection APIs are more than adequate for you to implememt such a thing. Reflection is the way to go in these statically typed languages; it's how Java libraries do it, and it's how C# does it. It's the only way to dynamically construct classes.
> 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"?
If you choose to spend your time on that, that's your choice. Why do you find it necessary? Do you really want to use a web service as an ORM?
Web applications come with no obligation to have a direct JSON <-> typesafe class mapping. Such mappings are ill-defined and bug prone if done automatically or with runtime reflection, and open to different styles of implementation. I don't think it's the job of the core library to solve that problem for you, not if it already allows you to work with JSON in other ways. Many people are fine to just use the Maps without the unjustified pretense of type safety, and other people are fine with manual mapping and validation. Considering the problems of reflective mapping and the availability of plenty of other solutions, I think you are being overzealous in your complaining.
I never said I didn't want it there; I said I didn't put it there. You can't tell me I have no right to put something on the homepage when it ended up there because of HN's algorithm (which suggests that others did want it there).
> Yes there is. Dart's reflection APIs are more than adequate for you to implememt such a thing
I was told by someone on the Dart Team: "using mirrors just isn't practical for real applications". If that's not actually true, great! However I suspect if it wasn't, then there would be a Dart-Team owned mirror-based implementation?
> Do you really want to use a web service as an ORM?
My data store is on a server; not in your browser. I need to get data (or some form) from the client back to the server, and vice versa. This is nothing to do with using a web service as an ORM, this is how web apps work - code runs in your browser, and needs to communicate with a server where I can retrieve or persist things. How do you think Gmail marks an email as Read when you open it? Fetches your email? etc.
> Web applications come with no obligation to have a direct JSON <-> typesafe class mapping. Such mappings are ill-defined and bug prone if done automatically or with runtime reflection
This is nonsense. Pulling data from a server into a Map is bug-prone, because if you use it as a map, all of your code can be wrong. If it's converted to a type, then only the mapping can be wrong, and the rest of the code can have static analysis. This is one of the selling points of Dart, and it's totally stupid to throw it away.
People are "ok" without the type safety because they have no other option. This is supposed to be one of the advantages of Dart over JS!
Don't confuse the argument. If you wanted it on the front page then you wanted to drag your entitlement beyond the original discussion onto the HN front page. You have many rights to do all sorts of things, but exercising it in this case just makes you seem entitled to me.
> This is nothing to do with using a web service as an ORM, this is how web apps work - code runs in your browser, and needs to communicate with a server where I can retrieve or persist things. How do you think Gmail marks an email as Read when you open it? Fetches your email? etc.
Don't strawman my argument. You need data client side, why is it necessary that they need to take the specific form of your own custom Dart classes mapping exactly to the shape of your JSON?
> This is nonsense. Pulling data from a server into a Map is bug-prone, because if you use it as a map, all of your code can be wrong. If it's converted to a type, then only the mapping can be wrong, and the rest of the code can have static analysis.
Maps have no pretense of type safety. Manual mappings have actual type safety. Reflection based automated mappings only have the pretense of type safety with a whole lot of problems.
I'm not saying reflection based mappings don't have merits. They do. But in a context where mapping-to-classes is not shown to be a necessity ("99% of all webapps" don't do that) and where there are plenty of alternatives, you are blowing up the problem.
> This is one of the selling points of Dart, and it's totally stupid to throw it away.
Except for the fact you're not really arguing for real type safety, I do agree. It is a missed opportunity in the Dart ecosystem. Does that really equate to Dart missing basic functionality? I think it just shows that it would be nice if there was a library for that. In the meantime, there are plenty of other things you can use.
I wanted it to be noticed, in the hope of getting an "official" response from someone that knows why we don' have it (or whether we'll ever get it). If you don't like that it's on the homepage; you can't blame me for that; the algorithm is based on HN users, not you.
> You need data client side, why is it necessary that they need to take the specific form of your own custom Dart classes mapping exactly to the shape of your JSON?
How is that at all what I'm asking for? I'm asking for to get data from a Dart class out of dart (via a string; I don't care if it's JSON), and then back in. This is a pretty basic need. I want the over-the-wire format to be documented so that I can use non-Dart on the server is required, and to avoid versioning issues. This seems like a pretty basic need for a web app?
> Reflection based automated mappings only have the pretense of type safety with a whole lot of problems
Rubbish. You can crash if the string doesn't deserialise exactly as expected; but then you get strong guarantees about the rest of your codebase that uses these types. Manual mapping is not a viable solution for any reasonable sized application.
> But in a context where mapping-to-classes is not shown to be a necessity ("99% of all webapps" don't do that)
That's garbage; it's not done now, because there's no ability to do that. One of the selling points of Dart is having typing; nobody would turn this down if it was easy and possible.
> and where there are plenty of alternatives, you are blowing up the problem.
All of the suggestion options have been criticised in the thread. Mirror-based is apparently no good for dart2js production code; protobuffers plugin doesn't work on Windows; and everything else needs manual mappings.
> It is a missed opportunity in the Dart ecosystem. Does that really equate to Dart missing basic functionality?
In my opinion; yes. Everyone is sending data back and forth to a server; they shouldn't need to write custom mapping code just to package it into a schema that gives type checking and code-completion.
You assert that Dart has, in principle, the ability to do that. But it doesn't. Not in the general case. No class-based programming language can solve this problem in general. You can have a close-to-complete solution (like C# and Java do), but that complexity is very unwanted for a language running in the browser.
Adding a language feature to Dart does not solve this problem either. Fitting dynamic data such as JSON or some other interchange format into a compiled definition in a typesafe way is just very hard. Writing validating mapping code really is the most robust thing to do.
So you end up with a fragile solution of large complexity. Or you can just write the mapping code yourself if you really really need it.
> Rubbish. You can crash if the string doesn't deserialise exactly as expected;
I'm going to use your own quote here: this "is not a viable solution for any reasonable sized application". Dart is made for large projects where type safety guarantees imply your project has a certain degree of correctness. If you want to undermine that by introducing crashes on bad mappings, then you have to do it yourself.
> Manual mapping is not a viable solution for any reasonable sized application.
There are plenty of "viable" projects out there with manual mapping of reasonable size. It's understandable that you don't feel particularly excited about writing that code. But don't blame that on the Dart developers. No other class based+statically typed+compile-to-JS language has the feature you desire, and I'm trying to tell you why.
There's nothing "bug prone" about pulling data into a Map (in fact, since that's all the semantics that JSON itself supports, anything "bug prone" about that is fundamental to JSON and unavoidable no matter what you pull it into.) It's bug prone to work with the Map as your domain object, but that's not something you need to do; you pull data into a Map, and then construct the object from the Map using a function designed for that purpose, likely something like a fromMap constructor.
Yes, there will need to be error handling in this mapping function because external data can never be assured to be error free, but you get all the benefits of type safety when working with the domain object.
I think that moto doesn't fit Dart at all, I use Dart and I have to make some workarounds that I just shouldn't be doing, but I have to because the language doesn't have the functionality that other languajes already have. The problem I see is that the Dart language developers never put them self in the shoes of the developer using their languaje.
In this case, I would be easy for them to add JSON serialization to objects, you know, but they didn't, why? polictics, apathy, whatever, but not technical problems.
So, my self, had to adapt to programming in Dart, so I every class must have a toJSON and fromJSON methods where I manually put the values to a map and then I use convert.JSON. But, I now I gave up using classes and now I just use Maps, just to write less code and is already the type Dart suppor for JSON serialization.
The word your looking for is "motto".
> I think that moto doesn't fit Dart at all, I use Dart and I have to make some workarounds that I just shouldn't be doing, but I have to because the language doesn't have the functionality that other languajes already have.
Newer languages that are comparatively young are usually going to have a less complete ecosystem and its a tradeoff between this and the unique features/approach they offer initially as the ecosystem matures.
> In this case, I would be easy for them to add JSON serialization to objects, you know, but they didn't, why?
Perhaps because they would have had to not do something else to get Dart released on the same timeline to do it. Lots of things are easy considered in isolation, but there are always opportunity costs, especially if you try to do every easy thing before you release anything.
I understand the complaint being made. And I explicitly note that there is a real trade-off. OTOH, I also recognize that there are real reasons why new languages don't spring into existence with complete language-native ecosystems on par with the most mature ecosystems in existence.
> it is very common to see that in fanboys.
I'm hardly a Dart fanboy. I think its a nice language that I'd rather work with than, say, JavaScript, and I like that someone is actually interested in challenging the assumption that JavaScript must be the one true language of the web, even if only as the common compilation target. But I don't have a real need for it, and its probably not even in the top 10 languages I'd use right now for a real project (though not having built-in JSON deserialization to user-defined classes isn't among the reasons why. Writing a converter to a custom type from the things it does deserialize JavaScript into isn't particularly challenging.)
Could that be explained because of not used to type safe languages? Type safe languages have a well-known clunkiness to dynamic type creation as well as other things. You get correctness in return, which is often worth it. It is also precisely the point of Dart's type system.
> In this case, I would be easy for them to add JSON serialization to objects, you know, but they didn't, why? polictics, apathy, whatever, but not technical problems.
This assertion is simply false. Adding arbitrary object creation support to a mostly statically typed language is not trivial at all [1]. What's more is that adding it will only give the guise of type safety when it's really not there.
[1]: See Jackson's source code, a popular Java (de)serialization library: https://github.com/FasterXML/jackson-core
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.
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.
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.
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.
>is ignorant of the associated complexities
Tell me what complexities?
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?
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.
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.
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?
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
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.
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.
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.
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.
Anyway, since you are starting in using sarcasm and I'm not interested in that kind of argument, so we are done here.
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?
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.
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/...
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.
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).
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.
We just starting hitting a bug in NHibernate where objects are GC'd that shouldn't, and it crashes. It was fixed in a newer version, so we updated. This minor update changed the way a bunch of queries work (optimisations that fail when a certain feature is used), and we've had to roll back. We either have Bug A or Bug B.
> How is abandoned 3rd party code any worse than code you wrote yourself?
I understand code I wrote myself and can easily fix bugs. The lsat thing I want to do when I find a bug in a 3rd party library is spend weeks debugging their code because it's been abandoned. In many cases it's a false economy.
> 3rd party code is almost always a win
I don't think you've worked on enough codebases you didn't write that are years old and had hundreds of dependencies pulled in without any thought; especially in something with no sound type-system like JS :O(
Try upgrading jQuery when you've got 150 jQuery plugins that have been abandoned and/or don't work in the new version of IE :-/
Can you cherry-pick just the fix you want? I'll admit this depends how intertwingled the fixes are...
> I understand code I wrote myself and can easily fix bugs.
I assumed you were in a team - which would level things out a bit even if you have pretty consistent coding standards. Yes - in a one man team the cost/benefit calculation might change.
> I don't think you've worked on enough codebases you didn't write that are years old and had hundreds of dependencies pulled in without any thought; especially in something with no sound type-system like JS :O(
Maybe this is the key to our different perspectives. I use lots of 3rd party code but it has to pass the smell test. I'm mainly talking about the Python ecosystem and I've probably learnt how to spot trouble and run away. My heuristics are based on code location:
(-5 if it's on Sourceforge or Launchpad, -3 if it's on Google code, -1 if it's on Bitbucket ;-)
and then stuff like documentation, number of forks and recency of commits - plus just the vibe I get skimming the code...
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.
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.
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?
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?