[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.

Cheers,
Jeff


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