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

Jeffery Olson olson.jeffery at gmail.com
Sun Jan 26 11:44:56 PST 2014

I have opened a PR against feral at
https://github.com/daftcorp/feral/pull/4. I hope my solution meets
with your approval.


On Sat, Jan 25, 2014 at 3:34 PM, Neil LoBracco <niceguyneil at gmail.com>wrote:

> Sure, Jeff. I've posted my work so far at
> https://github.com/daftcorp/feral
> (Feral from ferric oxide, which is rust...yeah, kind of a stretch, I know).
> Please disregard the commit messages with swears in them. I'm not used to
> the ownership model.
> Fundamentally, I'd like a controller (for example, controllers/foo.rs) to
> be able to say "encode this object I'm returning",  but not have to worry
> about how exactly that's going to happen. That sounds like Good Clean
> Architecture.
> Curious as to how you've handled this with your stuff, and if we can put
> together either a plan to make this system work more intuitively, or create
> some documentation about how to use the current framework in a clean manner.
>  -Neil
> On Sat, Jan 25, 2014 at 4:00 PM, Jeffery Olson <olson.jeffery at gmail.com>wrote:
>> 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/20140126/98c0b8bb/attachment-0001.html>

More information about the Rust-dev mailing list