[rust-dev] Understanding extra::{Encodable, Encoder}

Jeffery Olson olson.jeffery at gmail.com
Sat Jan 25 13:00:54 PST 2014

Do you have this code posted somewhere? I would want to take a look at it.

But, at first blush, I think part of (if not most of) the woe is around
using a trait object (~serialize::Encodable). I'm working with passing
around serializable objects, right now in my own codebase, and have
encountered pains as well. The API is really powerful/flexible, but you
need to heavily encapsulate where you expose those bounds and limit them as
much as possible (hint: JSON's field probably shouldn't actually be
restricted to only contain an Encodable<E>, because then you have to expose
E, which has the issues you describe).

 In a way, you're declaring a parameter bound by using Trait Objects
(~serialize::Encodable), but it would probably be more optimal to just
restrict the bounds to the methods where JSON variants can be constructed.

Sorry if this is a mess. It's hard to articulate.. As I said, I'd like to
take a look at the code, as this is an area of the library I've been
interested in and working with (with some success) recently.


On Sat, Jan 25, 2014 at 9:22 AM, Neil LoBracco <niceguyneil at gmail.com>wrote:

> Hey guys,
> I'm getting started with Rust, building out a web services framework.
> I have an enum methods can return for their response body:
> public enum ResponseBody {
>    Empty,
>    Text(~str),
>    JSON(~serialize::Encodable)
> }
> As you may know, this doesn't work, because Encodable expects a type
> parameter for Encoder. This is needed because Encodable has method:
> fn encode<http://static.rust-lang.org/doc/master/extra/serialize/trait.Encodable.html#tymethod.encode>(&self,
> s: &mut S);
> I can't even say JSON(~serialize::Encodable<json::Encoder>), because
> json::Encoder has a lifetime param that comes from its writer!
> It seems like this makes it impossible to ever take in a serializable
> object, and serialize it however I fancy. Moreover, it seems odd for the
> Encodable to know what it's encoded into - all of the logic that goes into
> actually turning an object into json/xml/whatever lives in json::Encoder,
> etc, so why should the Encodable be coupled with that?
> What makes sense to me would be to be able to say:
> pub fn stringify(obj : &Encodable) -> ~str {
>   let reader = json::Encoder::new(obj);
>   reader.read_to_str()
> }
> Where the Encoder trait implies the Reader trait. If something were
> Encodable, that would not be specific to any particular Encoder - it would
> be a general statement.
> Anyone have thoughts about this? Am I missing any easy way I would be able
> to do what I asked above (take in a ~Encodable and encode it to buffer,
> without having whoever created the encodable have to know about the writer
> that would eventually get used)?
> If we want to make changes here, I can certainly help out with that, just
> wanted to understand what's going on here and the rationale.
> Thanks,
> -Neil
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140125/be2864c9/attachment.html>

More information about the Rust-dev mailing list