4 ms·

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(custom

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: x =~= JSON.decode(JSON.encode(x)). (where x =~= y means that the two objects are Json-equivalent). - The Dart-Editor already provides a quick-fix to write a toJson for you. To be honest I'm not really a fan of it, since I believe that serialization information should be outside the object, and not in the object (that's what "toEncodable" is for), but that's another story. - It's extremely 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't force it on all users.

syntern 13y ago
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?
- floitsch 13y ago
  It was recently added, but apparently removed again. (I don't know the exact reasons). Edit. you can see the announcement here: https://plus.google.com/109866369054280216564/posts/XbjvN5QVpn9 https://plus.google.com/109866369054280216564/posts/XbjvN5QV... Edit2. Removal of the feature: https://code.google.com/p/dart/issues/detail?id=16425 https://code.google.com/p/dart/issues/detail?id=16425
Max_Horstmann 13y ago
I certainly agree with the latter point if adding a default/out of the box JSON serialization does indeed add significant overhead, impacting all users including those which don’t require it. On the flipside, if a cost-effective solution can be found – e.g. by providing a default JSON serialization via class annotations – I feel that it should be part of Dart’s core and not up to individual developers to home-brew their own solution to a very common problem. In the particular case of DateTime, I’m pretty sure that adding a default JSON serialization now will increase interoperability between Dart-based services and sites in the future.

syntern 13y ago

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?

floitsch 13y ago
It was recently added, but apparently removed again. (I don't know the exact reasons). Edit. you can see the announcement here: https://plus.google.com/109866369054280216564/posts/XbjvN5QVpn9 https://plus.google.com/109866369054280216564/posts/XbjvN5QV... Edit2. Removal of the feature: https://code.google.com/p/dart/issues/detail?id=16425 https://code.google.com/p/dart/issues/detail?id=16425

Max_Horstmann 13y ago

I certainly agree with the latter point if adding a default/out of the box JSON serialization does indeed add significant overhead, impacting all users including those which don’t require it. On the flipside, if a cost-effective solution can be found – e.g. by providing a default JSON serialization via class annotations – I feel that it should be part of Dart’s core and not up to individual developers to home-brew their own solution to a very common problem. In the particular case of DateTime, I’m pretty sure that adding a default JSON serialization now will increase interoperability between Dart-based services and sites in the future.