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

Neil LoBracco niceguyneil at gmail.com
Sat Jan 25 15:34:42 PST 2014


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/20140125/78c0d7ad/attachment.html>


More information about the Rust-dev mailing list