I was the TL of the libraries for almost a year, and there are good reasons we didn't go this route: - it adds overhead. Being able to write JSON.encode(customer) would mean that every class needs to retain its field names. Minification could still work if this information is stored on the side, but it would add overhead. - it doesn't make sense to automatically encode elements that cannot be decoded. You should have…
Why Dart should learn JSON while it’s still young
11–20 of 55 posts
Re: Why Dart should learn JSON while it’s still young
#12Take this parting remark:
> So, here’s another thing I wanna add to my suggestion: consider adapting ISO 8601 for a default JSON serialization of DateTime, so the following just works:
> var dt = DateTime.parse("2014-01-26T11:38:17");
> print(JSON.encode(dt));
Ignoring the fact that it's a simple value you're attempting to encode to JSON, let's say this works. Do you get:
"2014-01-26T11:38:17"
Now do to the reverse: what does that decode to? Either it decodes to a string, and you've lost the type information, or it decodes to a date, in which case, what does `JSON.encode("2014-01-26T11:38:17")` decode to? i.e., do strings sometimes decode to dates? What if someone uses what should be a string to cause the decoder to decode it as a date? Now anywhere you have a string, it might decode to a date!YAML has support for this sort of thing, with a syntax like `!!date "2014-01-26T11:38:17"`. (If you want a literal `!!`, it's always `"!!"`.) Notably, the Python library for YAML can do what the author asks: encode and decode arbitrary objects. (but it turns out to be a security risk to do so on untrusted data.)
> The Dart editor should be able to display a JSON serialization of anything the mouse pointer touches.
If my class contains a file handle, what's the JSON representation of a file handle? Further, if I send that serialization across the wire, how do you deserialize it? I mention this because you can't, at least, not really. Python's `repr` is a good example here. When it can, it gives you close-to Python syntax for the object, such as strings (`"hello world"`), ints (`1`), decimals (`Decimal(3)`), etc. Perfect for debugging. For things it can't, you get something like `` — which doesn't parse (on purpose) as Python.
I'd venture to say that what you really want is the ability to introspect. Take your customer example: if you could introspect it, and see what member variables were present, you could build a function that might output:
{"type": "Customer", {"Id": 1, "Name": "Joe Bob"}}
Again, note the explicit serialization of the type here, in JSON. This is something I made up, of course, and not JSON. Of course, some language feature can make introspection interesting. (Can you even get a list of members? Some languages allow objects to make up members on-the-fly.)Hopefully, I've convinced you language design is hard. :-)
Re: Why Dart should learn JSON while it’s still young
#13This is more complicated than it seems. First, how does it work with minimization? In Dart, string constants are not minimizable (will be included as-is in the source code). Symbol constants will be minimized. This includes all method names, field names, and things like named parameters. You can see this in the arguments to noSuchMethod; the named parameters map has Symbol keys, not strings. Probably something could…
All I seem to hear is people complaining about it.
Given so little effort is given to it, I halfway think they should just give up on javascript and javascript interop completely and focus on making dart awesome.
Anyhow, what you say is totally true, but surely iterating recursively over an object and dumping values into a json block would be trivial.
The hard part is deserializing that back into objects, but maybe you dont need to? The python json package does a pretty good job. You could just have it return a dynamic or something.
Re: Why Dart should learn JSON while it’s still young
#14Is there still people willing to use Dart instead of Javascript for web now? (no irony)
Yes. For some use cases the speed of development and rapid prototyping is worth it.
Its really only plausible for very specific project where these arent issues.
Re: Why Dart should learn JSON while it’s still young
#15This is more complicated than it seems. First, how does it work with minimization? In Dart, string constants are not minimizable (will be included as-is in the source code). Symbol constants will be minimized. This includes all method names, field names, and things like named parameters. You can see this in the arguments to noSuchMethod; the named parameters map has Symbol keys, not strings. Probably something could…
Re: Why Dart should learn JSON while it’s still young
#16I was the TL of the libraries for almost a year, and there are good reasons we didn't go this route: - it adds overhead. Being able to write JSON.encode(customer) would mean that every class needs to retain its field names. Minification could still work if this information is stored on the side, but it would add overhead. - it doesn't make sense to automatically encode elements that cannot be decoded. You should have…
Where is toJson in the Dart Editor? (I'm looking for it in 1.1.1, but couldn't figure it out.) And does it have a fromJson generator too?
Edit. you can see the announcement here: https://plus.google.com/109866369054280216564/posts/XbjvN5QV...
Edit2. Removal of the feature: https://code.google.com/p/dart/issues/detail?id=16425
Re: Why Dart should learn JSON while it’s still young
#17Re: Why Dart should learn JSON while it’s still young
#18This is more complicated than it seems. First, how does it work with minimization? In Dart, string constants are not minimizable (will be included as-is in the source code). Symbol constants will be minimized. This includes all method names, field names, and things like named parameters. You can see this in the arguments to noSuchMethod; the named parameters map has Symbol keys, not strings. Probably something could…
does anything actually work with dart2js? All I seem to hear is people complaining about it. Given so little effort is given to it, I halfway think they should just give up on javascript and javascript interop completely and focus on making dart awesome. Anyhow, what you say is totally true, but surely iterating recursively over an object and dumping values into a json block would be trivial. The hard part is deseria…
The dart2js team is one of the teams with the most developers on it. There is a huge effort going into it.
Dart2js generally does a good job, but a few features (like mirrors) that are still in beta-quality, are currently a constant source of grieve for the developers. We would have liked to delay their release until they were more stable, but several customers really, really needed them.
Things are getting better, though, and I hope that dart2js will fade into the background (as a simple working tool) soon.
Re: Why Dart should learn JSON while it’s still young
#19For example, if you use a magic serializer, your properties might have to follow a different capitalization format than what's normal for your language.
Recently, I ported some Java code to C#. It was written with a magic JSON serializer. When I got to test my port, nothing worked! It turns out that Java's serializer used lowercase names in JSON, but my serializer used uppercase names! The magic, unfortunately, didn't work, because assumptions that were valid in Java did not carry over to C#.
I think it's best to think of magic serializers as rapid prototyping tools that work well when both ends are the same languages. Thus, while might be useful for Dart to include one very simple quick-and-dirty serializer to JSON, any production code of merit will most likely outgrow it.
Re: Why Dart should learn JSON while it’s still young
#20Earlier quoted context omitted.
Yes. For some use cases the speed of development and rapid prototyping is worth it.
...but there are unavoidable severe limitations like slow js interop, large file size and poor browser compatibility. Its really only plausible for very specific project where these arent issues.