I have opened a PR against feral at https://github.com/daftcorp/feral/pull/4. I hope my solution meets with your approval.
Cheers, Jeff On Sat, Jan 25, 2014 at 3:34 PM, Neil LoBracco <[email protected]>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 <[email protected]>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 <[email protected]>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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
