serialize: impl ToJson for all Encodables

[seanmonstar]

I just wanted to submit this at this point to see if something like this would be accepted. If so, I can clean it up some more, such as converting to Vec<T>, etc.

The short is that this is now possible:

#[deriving(Encodable)]structFoo{bar:uint}
foo.to_json();// => json::Object(TreeMap)

fixes#8335

[alexcrichton]

I'm a little sad to see yet another encoder in the json module. I would expect there to be one encoder, not three. Two is already pushing it a little bit. I fear that the json modules needs to be thought out before tacking on more functionality.

From what it looks like, the are three different representations that the json module deals with: rust values, strings, and values of type Json. The current module implements

from	to	implemented
rust	json	no
rust	string	yes (Encoder)
json	string	yes (Encoder)
json	rust	yes (Decoder)
string	rust	no
string	json	yes (Parser)

This is a bit of a hefty matrix to deal with, and I fear the utility of the Json type is diminished due to how it's used. In the ideal world, I would expect the json module to contain:

• One encoder, which is an implementation of the Encoder trait.
• One decoder, which is an implementation of the Decoder trait.
• A Json enum which implements encodable/decodable

I would imagine that the decoder is what the parser is today, and that this intermediate format of Json isn't used that often. Instead it's only used if the format being deserialized isn't known ahead of time.

What do you think of this?

[seanmonstar]

Personally, I was surprised to read in #8335 the need to turn a rust object into a Json, but not all the way to a string. Even the name of the trait, ToJson, gives me pause. I think of JSON as a string. Always. If it's not a string, it's something else. So, I assume ToJson.to_json() to return a string.

I also think the Encoder and PrettyEncoder could be just one encoder, with a few ifs in the methods. If that's preferred, I can clean up this module that way.

[alexcrichton]

That sounds good to me! Here's a few things that I think would work well:

• Merging Encoder and PrettyEncoder with a flag (as you suggested)
• Removing ToJson
• Delete Decoder and rename Parser to Decoder (folding all functionality into one another)
• Keep the Json enum, implementing Encodable/Decodable for it

That way you use the Decoder to go from a string to a rust value and the Encoder to go from a rust value to a string. Conversion between rust values and a Json value would require going through a string. You can also always decode directly into a Json value if you need to inspect the object.

[seanmonstar]

Why remove the Parser? Looking in ebml, theres a parser-like object, and the decoder is separate.

[alexcrichton]

ebml isn't necessarily the gold standard for libraries, and the Parser's functionality would remain, it would just live under a new name.

[seanmonstar]

is there any need to keep the Json enum around? Why not decode straight from a string?

If it does stick around, I can't figure out how I would implement Decodable for Json. There doesn't seem to be any way to get a hint of the next value. Can I use some matching? Or use the Any trait somehow?:

impl<D:Decoder>Decodable<D>forJson{fn(d:&mutD) -> Json{// can i somehow match against types?matchDecodable::decode(d){
f64 => Number,// etc?}}}

[alexcrichton]

Keeping Json around seems useful because you can deserialize an arbitrary blob into it.

You don't need to implement <D: Decoder> Decodable<D>, you can implement Decodable<JsonDecoder>.

[erickt]

This should be to_json instead of into_json, or instead it should consume self. We've standardized on using into_ to represent methods that consume self to transform into the result`. Also, this should return an error type instead of failing.

[seanmonstar]

I'll open a new PR of json cleanup. I've also found the error handler in Encoder's to unfun, so I might fix #12292 before.