TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why Dart should learn JSON while it’s still young

108 pointsby Max_Horstmannover 11 years ago

18 comments

skybrianover 11 years ago
This is more complicated than it seems.<p>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.<p>Probably something could be worked out, though. Maybe put an annotation on the customer class to tell the compiler to save the original field names?<p>But a second issue is how it works with inheritance, including mixins. If a class is serializable, does that make all the superclasses and subclasses serializable as well? JSON doesn&#x27;t have a standard way to represent a type tag, so does that mean we should invent one? If we do that, what happens to JSON interop with other languages?<p>Also keep in mind that Dart supports types that don&#x27;t interop with JavaScript like unlimited precision integers. (Well, okay, that only works with the Dart VM, not dart2js...)<p>It gets worse. What if your class has a field type like List&lt;dynamic&gt;, which could contain any object? Does that mean the Dart compiler now has to preserve all symbols because any class could be serialized? And keep in mind that with optional types, all lists should behave the same when not in checked mode.<p>Having seen the mess that resulted in GWT-RPC, I would recommend just saying no to default serialization. Serialization and object inheritance don&#x27;t really mix well which is why specs like JSON and protobufs don&#x27;t support it.<p>(And now you know why language designers don&#x27;t throw things into a language just because it seems like a good idea at the time.)
评论 #7160970 未加载
评论 #7160497 未加载
评论 #7160509 未加载
floitschover 11 years ago
I was the TL of the libraries for almost a year, and there are good reasons we didn&#x27;t go this route:<p>- 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.<p>- it doesn&#x27;t make sense to automatically encode elements that cannot be decoded. You should have: x =~= JSON.decode(JSON.encode(x)). (where x =~= y means that the two objects are Json-equivalent).<p>- The Dart-Editor already provides a quick-fix to write a toJson for you. To be honest I&#x27;m not really a fan of it, since I believe that serialization information should be outside the object, and not in the object (that&#x27;s what &quot;toEncodable&quot; is for), but that&#x27;s another story.<p>- It&#x27;s <i>extremely</i> easy to get the behavior you want. Just use (or write, if none exists yet) a package that has your intended behavior. This is really a one-line change... This way you pay the price when you want to, and don&#x27;t force it on all users.
评论 #7166086 未加载
评论 #7160471 未加载
grimlckover 11 years ago
What&#x27;s wrong with just using a library?<p>Scala learnt XML while it was still young, when XML was just as popular as JSON is now, yet incorporating XML into the language is now considered a mistake.
gwbas1cover 11 years ago
The problem with magic serializers is that they tend to be brittle in practice. This is because the assumptions they make don&#x27;t work across languages.<p>For example, if you use a magic serializer, your properties might have to follow a different capitalization format than what&#x27;s normal for your language.<p>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&#x27;s serializer used lowercase names in JSON, but my serializer used uppercase names! The magic, unfortunately, didn&#x27;t work, because assumptions that were valid in Java did not carry over to C#.<p>I think it&#x27;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.
tyleregetoover 11 years ago
Golang has great JSON support that I think could translate to Dart. Any overhead could be minimized through compiler support so we don&#x27;t have to rely on the current mirror functionality. I think that would be a nice balance between what the author of this article is asking for and dart2js performance.
评论 #7160856 未加载
oscargrouchover 11 years ago
Is there still people willing to use Dart instead of Javascript for web now? (no irony)
评论 #7160329 未加载
deathanatosover 11 years ago
It&#x27;s the type data that makes this hard: JSON has no support for encoding new types into the serialization. This is a blessing and a curse: it makes JSON simple, but also inflexible.<p>Take this parting remark:<p>&gt; 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:<p>&gt; var dt = DateTime.parse(&quot;2014-01-26T11:38:17&quot;);<p>&gt; print(JSON.encode(dt));<p>Ignoring the fact that it&#x27;s a simple value you&#x27;re attempting to encode to JSON, let&#x27;s say this works. Do you get:<p><pre><code> &quot;2014-01-26T11:38:17&quot; </code></pre> Now do to the reverse: what does that decode to? Either it decodes to a string, and you&#x27;ve lost the type information, or it decodes to a date, in which case, what does `JSON.encode(&quot;2014-01-26T11:38:17&quot;)` 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!<p>YAML has support for this sort of thing, with a syntax like `!!date &quot;2014-01-26T11:38:17&quot;`. (If you want a literal `!!`, it&#x27;s always `&quot;!!&quot;`.) Notably, the Python library for YAML <i>can</i> 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.)<p>&gt; The Dart editor should be able to display a JSON serialization of anything the mouse pointer touches.<p>If my class contains a file handle, what&#x27;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&#x27;t, at least, not really. Python&#x27;s `repr` is a good example here. When it can, it gives you close-to Python syntax for the object, such as strings (`&quot;hello world&quot;`), ints (`1`), decimals (`Decimal(3)`), etc. Perfect for debugging. For things it can&#x27;t, you get something like `&lt;file object &quot;~&#x2F;foo.txt&quot; at 0xdeadbeef&gt;` — which doesn&#x27;t parse (on purpose) as Python.<p>I&#x27;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:<p><pre><code> {&quot;type&quot;: &quot;Customer&quot;, {&quot;Id&quot;: 1, &quot;Name&quot;: &quot;Joe Bob&quot;}} </code></pre> Again, note the explicit serialization of the type here, in JSON. This is something <i>I</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.)<p>Hopefully, I&#x27;ve convinced you language design is hard. :-)
评论 #7161459 未加载
daurnimatorover 11 years ago
You don&#x27;t just want ISO 8601, but more exactly: RFC 3339 (a subset)
评论 #7160248 未加载
TillEover 11 years ago
The lack of easy serialization is pretty strange. Even on stodgy old non-dynamic versions of C#, YamlDotNet does a really good job of translating arbitrary objects to and from YAML&#x2F;JSON just using reflection.
评论 #7160812 未加载
cwpover 11 years ago
Yes, it would be great if everything always just worked, and libraries always had your desired behavior as the default. Google should implement that right away.
the_gipsyover 11 years ago
I was recently writing a JSON un&#x2F;serializing component in TypeScript, which is much nearer to JavaScript than Dart I believe, and even though I just had to make it work with a few certain types I knew in advance, it was still a PITA. I don&#x27;t think there&#x27;s a good way to JSON-to-anything-serializing, you always end up with some type related &quot;tags&quot; which shouldn&#x27;t really be in the JSON data.
coldteaover 11 years ago
Thanks, was thinking of delving into Dart, but between the mediocre JS interop and this, I decided not to. Not to mention that ES6 brings tons of goodies to JS too, and the speed difference is not that great anyways.<p>Great JSON integreation is one of the things I enjoy most from Javascript (well, it makes sense given the J in JSON).
pjmlpover 11 years ago
Personally I only care about JavaScript and am looking forward to ES6.<p>I don&#x27;t care about transpilers and still looking for a use case worthwhile for Dart.<p>Unless Google pushes it, for example as Android language, ChromeOS or whatever might be the language killer application.
评论 #7161123 未加载
Max_Horstmannover 11 years ago
Thanks for all the great feedback! I&#x27;ve updated the blog post with some of the key points from this discussion.
thatthatisover 11 years ago
Learn JSON, but please for the love of Turing&#x27;s ghost, teach it to use trailing commas.<p>So many needless syntax errors.
outside1234over 11 years ago
Dart should be JavaScript. Seriously, what&#x27;s the point of Dart again?
评论 #7160747 未加载
munroover 11 years ago
Dart is actually trying to teach the web about static typing.
评论 #7161454 未加载
r0manover 11 years ago
We should all support EDN