

Google's Dart doesn't support deserialising JSON (or anything) into Dart Types - d2p
https://groups.google.com/a/dartlang.org/forum/#!topic/misc/0pv-Uaq8FGI

======
kyrra
This seems like a non-issue to me. Serialization isn't built into the core
libraries, but there are a number of 3rd party libraries that will serialize
from various data formats. Dart has mirrors (reflection) which allows any kind
of population of Dart types from other data types.

~~~
d2p
Did you read about any of the suggested options? They all basically suck;
requiring tons of boilerplate; are not-static formats (making it difficult to
implement "the other side"); poor performance; and mostly implemented by third
parties so they'll likely be broken or abandoned in 6 months.

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?

~~~
WoodenChair
I think it would be respectful if you mentioned that you are the starter of
the thread on the mailing list in the first place...

~~~
d2p
Apologies; it's been so long since I signed up, I didn't realise my username
was quite so cryptic. The thread is indeed mine, and I posted it here in the
hope that it might be seen by someone on the Dart Team, as there seems to have
been no response from Google on this hole :(

~~~
WoodenChair
I can assure you that the Dart team reads the mailing list and has almost
certainly seen your thread there. I appreciate (and can see) that you honestly
want to help Dart succeed, but the title of this thread along with the tone of
your comments in the mailing list thread I find to be filled with hyperbole. I
don't think calling out the team publicly with a misleading title was the best
way to go about helping the language.

~~~
d2p
I'm sorry if it sounds like I'm being a dick; but I'm incredibly frustrated to
have poured so much effort into trying to make Dart a viable option for a
rewrite where I work (I've even been working on a Visual Studio extension
since all the devs here are primitively .NET devs).

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.

~~~
frowaway001
I'm kind of interested why you considered Dart in the first place.

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.

~~~
d2p
I wrote a blog post some time ago:

[http://blog.dantup.com/2014/05/web-development-sucks-and-
its...](http://blog.dantup.com/2014/05/web-development-sucks-and-its-not-
getting-any-better/)

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.

------
colanderman
Justin Fagnani's response hits it head on. It makes no sense to deserialize
schema-less JSON into objects. How is the compiler to know what classes you
want it to use? Even if you just want classes with no methods, the
deserializer still needs to know what fields you expect. (Otherwise you have
no guarantee what fields the object you're returned has, which is pretty
useless!)

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.

~~~
d2p
The class you're deserialising into is the Schema; exactly like C# manages to
do it:

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!

~~~
rst
This may be easier in C# than in Dart because in C#, you have type
declarations for all the members. In Dart, type declarations are optional.
(And, IIRC, not supposed to change the behavior of the program, except for
type-checks performed while running in "development" mode; even these are
disabled in "production".)

------
DCKing
I think many people are satisfied with the alternatives presented in that
thread. A very large percentage will probably even be happy with the
serialization to Lists and Maps - because that is what JavaScript already
does! I understand that you have your preferences, and you are entitled to
have those. In my opinion, you are not entitled to:

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

[1]:
[https://code.google.com/p/dart/wiki/Contributing](https://code.google.com/p/dart/wiki/Contributing)

~~~
adrianlmm
The moto of Dart is to make the life easier for developers.

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.

~~~
dragonwriter
> The moto of Dart is to make the life easier for developers.

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.

~~~
adrianlmm
Are you part of the Dart team?

~~~
dragonwriter
No.

~~~
adrianlmm
Then I get the impression you are defending Dart just by inertia and not
because you understand the problem, it is very common to see that in fanboys.

~~~
dragonwriter
> Then I get the impression you are defending Dart just by inertia and not
> because you understand the problem

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

~~~
adrianlmm
Then the fact you don't face the same problem that we do, doesn't mean that
the problem doesn't exists.

------
TeeWEE
It seems to me the author should think twice about rewriting an entire code
base in a new language. This almost always leads to disaster, and often doesnt
give you a lot of value.

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.

~~~
d2p
There are lots of details about what we're rewriting any why that aren't
really relevant to this discussion.

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

~~~
andybak
> poor libraries introducing breaking changes

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.

~~~
d2p
> Don't update unless you have to?

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 :-/

~~~
andybak
> We either have Bug A or Bug B

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

------
jdonaldson
One thing Haxe does well here is provide structural typing, effectively
letting you declare the result of a deserialization process in type form.

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.

~~~
jdonaldson
quick sketch: [http://try.haxe.org/#db206](http://try.haxe.org/#db206)

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.

------
marktangotango
I'm not familiar with Dart, but it seems like since it has object(map)/list
literal syntax similar to Javascript, deserializing a simple object (no
methods) from a string of characters would be trivial. JSON really is a
Javascript killer feature imo.

~~~
d2p
It does support deserialising into a _map_ , but not a class. One of the
selling points of Dart is classes; which can give code-completion, static
analysis, etc.. This is all lost if you use maps instead of classes.

~~~
sigzero
The top comment as well as the answer in the thread explains why.

~~~
d2p
Not really; that comment is incorrect. For example, in C# there's a
JavaScriptSerializer.Deserialize<T>(string) method that does just this.

------
clubhi
When I was a kid you used to serialize to JSON.

------
easytiger
The stupidity of the question is causing me to have neural pathway executions
that are akin to an electoral storm.

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?

~~~
d2p
Many products are > 1m LoC. I never said those 1m LoC are in one file (or even
one repository).

~~~
easytiger
1m LoC are in one file (or even one repository).

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?

~~~
d2p
The reason for a rewrite is beyond the scope of Dart supporting sane
serialisation. There are many reasons; but here is not an appropriate place to
detail them.

