Comment by DCKing | Hacker News Reader

Comment by DCKing | Hacker News Reader

Parent Full thread

> Your opinion is no more fact than mine.

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.

> Come on. You submitted it, and did not want it on the front page?

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!

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

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.

> If you wanted it on the front page then you wanted to drag your entitlement beyond the original discussion onto the HN front page

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.

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

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.

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

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.

Reply on news.ycombinator.com