-
Notifications
You must be signed in to change notification settings - Fork 31
Value is not Decodable after the move to associated types #44
Comments
I also suffer from new Rust
But how? By reading a single byte one-by-one via read_u8() and analyzing it with further decoding? |
In looking at Instead they have a Then their implementation of Decoder just runs through this parsed representation.
The unfortunate thing about this strategy is that it appears to require reading the stream to completion. |
This is bad for me, because I use msgpack in conjunction with TcpStream, which yields msgpack object every time it's ready. |
It's worth noting the distinction: the In practice I can't say I've ever done that. I usually pull If you really need to do streaming (e.g: you're receiving fragments of a message) then you would have to use |
I have a branch that has been tracking rustc-serialize: drbawb/rust-msgpack/feature/rustc-serialize
After the latest changes to the serialize crate (see rust-lang/rust/pull/20514) I have been having lots of issues adopting the current architecture of the library to use associated types.
The biggest hurdle is that the signature of Decodable has changed to the following:
Where
D
is bound by the traitserialize::Decoder
.This means that inside the decode function we do not have access to the concrete
msgpack::Decoder<R>
any more.The previous definition of
serialize::Decodable for Value
relied on calling themsgpack::Decoder::decode_value()
method, which is obviously not accessible through the Decoder trait.I can't see any way to get access to the concrete decoder.
I even tried
std::mem::transmute
but because the type parameters for the underlyingReader
is also removed from theserialize::Decoder
trait: we lack the necessary type information to perform such a cast.It would appear that the only option left is to re-implement
msgpack::Decoder#decode_value()
in terms of the genericserialize::Decoder
trait.The text was updated successfully, but these errors were encountered: