-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix build warnings and a few assorted tweaks #13
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,68 +6,92 @@ use rand::{ | |
}; | ||
|
||
use crate::{ | ||
alkahest, read_packet, write_packet_to_vec, Formula, Lazy, SerIter, Serialize, SerializeRef, | ||
alkahest, read_packet, write_packet_to_vec, Deserialize, Formula, Lazy, SerIter, Serialize, SerializeRef, Ref, | ||
}; | ||
|
||
#[alkahest(Formula)] | ||
pub enum GameMessageFormula { | ||
Client(Ref<ClientMessageFormula>), | ||
Server(Ref<ServerMessageFormula>), | ||
} | ||
|
||
#[derive(Debug, Clone, PartialEq, Eq)] | ||
#[alkahest(Formula, Serialize, Deserialize)] | ||
#[alkahest(Serialize<GameMessageFormula>, Deserialize<'_, GameMessageFormula>)] | ||
pub enum GameMessage { | ||
Client(ClientMessage), | ||
Server(ServerMessage), | ||
} | ||
|
||
#[derive(Debug)] | ||
#[alkahest(Deserialize<'de, GameMessage>)] | ||
#[alkahest(Deserialize<'de, GameMessageFormula>)] | ||
pub enum GameMessageRead<'de> { | ||
Client(ClientMessageRead<'de>), | ||
Server(ServerMessageRead<'de>), | ||
} | ||
|
||
#[alkahest(Formula)] | ||
pub enum ClientMessageFormula { | ||
ClientData { nickname: Ref<str>, clan: Ref<str> }, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right :D Which is cool There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So why making separate type? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It was not obvious to me from documentation what a formula actually is -- that it is a rust type that mirrors the type you want that contains types which have a direct exact representation. Making this split it becomes more obvious what's going on -- in my eyes at least. And it shows how you can create multiple formulas which the same type can serialize as / deserialize from, or customize the exact representation with wrappers like Whether the proper place for that is in a test like here: perhaps not x) but I was just playing around with it to get a better idea of how things work. Probably it should go in a separate test/example to show it better. I would be fine with reverting the formula changes in this file for sure. |
||
Chat(Ref<str>), | ||
} | ||
|
||
#[derive(Debug, PartialEq, Eq, Clone)] | ||
#[alkahest(Formula, Serialize, Deserialize)] | ||
#[alkahest(Serialize<ClientMessageFormula>, Deserialize<'_, ClientMessageFormula>)] | ||
pub enum ClientMessage { | ||
ClientData { nickname: String, clan: String }, | ||
Chat(String), | ||
} | ||
|
||
#[derive(Debug)] | ||
#[alkahest(Deserialize<'de, ClientMessage>)] | ||
#[alkahest(Deserialize<'de, ClientMessageFormula>)] | ||
pub enum ClientMessageRead<'de> { | ||
ClientData { nickname: &'de str, clan: &'de str }, | ||
Chat(&'de str), | ||
} | ||
|
||
#[alkahest(Formula)] | ||
pub enum ServerMessageFormula { | ||
ServerData(u64), | ||
ClientChat { client_id: u64, message: Ref<str> }, | ||
} | ||
|
||
#[derive(Debug, PartialEq, Eq, Clone)] | ||
#[alkahest(Formula, Serialize, Deserialize)] | ||
#[alkahest(Serialize<ServerMessageFormula>, Deserialize<'_, ServerMessageFormula>)] | ||
pub enum ServerMessage { | ||
ServerData(u64), | ||
ClientChat { client_id: u64, message: String }, | ||
} | ||
|
||
#[derive(Debug)] | ||
#[alkahest(Deserialize<'de, ServerMessage>)] | ||
#[alkahest(Deserialize<'de, ServerMessageFormula>)] | ||
pub enum ServerMessageRead<'de> { | ||
ServerData(u64), | ||
ClientChat { client_id: u64, message: &'de str }, | ||
} | ||
|
||
#[alkahest(Formula)] | ||
pub struct NetPacketFormula<F> { | ||
pub game_messages: Vec<F>, | ||
} | ||
|
||
#[derive(Debug)] | ||
#[alkahest(Formula, Serialize, Deserialize)] | ||
#[alkahest(for<F: Formula> Serialize<NetPacketFormula<F>> where G: Serialize<F>)] | ||
#[alkahest(for<'de, F: Formula> Deserialize<'de, NetPacketFormula<F>> where G: Deserialize<'de, F>)] | ||
pub struct NetPacket<G> { | ||
pub game_messages: Vec<G>, | ||
} | ||
|
||
#[derive(Debug)] | ||
#[alkahest(for<X: Formula> Serialize<NetPacket<X>> where G: Serialize<[X]>)] | ||
#[alkahest(for<X: Formula> SerializeRef<NetPacket<X>> where G: SerializeRef<[X]>)] | ||
#[alkahest(for<F: Formula> Serialize<NetPacketFormula<F>> where G: Serialize<[F]>)] | ||
#[alkahest(for<F: Formula> SerializeRef<NetPacketFormula<F>> where G: SerializeRef<[F]>)] | ||
pub struct NetPacketWrite<G> { | ||
pub game_messages: G, | ||
} | ||
|
||
#[derive(Debug)] | ||
#[alkahest(Deserialize<'de, NetPacket::<G>> where G: Formula)] | ||
pub struct NetPacketRead<'de, G> { | ||
pub game_messages: Lazy<'de, [G]>, | ||
#[alkahest(Deserialize<'de, NetPacketFormula<F>> where F: Formula)] | ||
pub struct NetPacketRead<'de, F> { | ||
pub game_messages: Lazy<'de, [F]>, | ||
} | ||
|
||
fn get_string(rng: &mut impl Rng) -> String { | ||
|
@@ -103,15 +127,15 @@ fn test_net_packet() { | |
const LEN: usize = 1000; | ||
|
||
let mut buffer = Vec::new(); | ||
let size = write_packet_to_vec::<NetPacket<GameMessage>, _>( | ||
let size = write_packet_to_vec::<NetPacketFormula<GameMessageFormula>, _>( | ||
NetPacketWrite { | ||
game_messages: SerIter(messages(rng.clone(), LEN)), | ||
}, | ||
&mut buffer, | ||
); | ||
|
||
let mut buffer2 = Vec::new(); | ||
let size2 = write_packet_to_vec::<NetPacket<GameMessage>, _>( | ||
let size2 = write_packet_to_vec::<NetPacketFormula<GameMessageFormula>, _>( | ||
NetPacket { | ||
game_messages: messages(rng, LEN).collect::<Vec<_>>(), | ||
}, | ||
|
@@ -122,23 +146,23 @@ fn test_net_packet() { | |
assert_eq!(buffer[..size], buffer2[..size]); | ||
|
||
let (packet, _) = | ||
read_packet::<NetPacket<GameMessage>, NetPacketRead<GameMessage>>(&buffer[..]).unwrap(); | ||
read_packet::<NetPacketFormula<GameMessageFormula>, NetPacketRead<GameMessageFormula>>(&buffer[..]).unwrap(); | ||
|
||
for message in packet.game_messages.iter::<GameMessageRead>() { | ||
match message.unwrap() { | ||
GameMessageRead::Client(ClientMessageRead::ClientData { nickname, clan }) => { | ||
drop(nickname); | ||
drop(clan); | ||
let _ = nickname; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Any reason for this besides style? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Clippy doesn't like dropping references and says to ignore it via There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If default-configured clippy says so I have no objections. |
||
let _ = clan; | ||
} | ||
GameMessageRead::Client(ClientMessageRead::Chat(message)) => { | ||
drop(message); | ||
let _ = message; | ||
} | ||
GameMessageRead::Server(ServerMessageRead::ServerData(data)) => { | ||
drop(data); | ||
let _ = data; | ||
} | ||
GameMessageRead::Server(ServerMessageRead::ClientChat { client_id, message }) => { | ||
drop(client_id); | ||
drop(message); | ||
let _ = client_id; | ||
let _ = message; | ||
} | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
Ref
looks unnecessary hereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yeah, I was just experimenting with it -- this is actually the reason I initially wanted to separate the formula from the serialize and deserialize types, to insert a wrapping handler in the mix. Ultimately I'm trying to play with making a
Ref
-like wrapper that would help to do schema evolution (forward/backward compatibility). But it is of course unnecessary in this case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What exactly are properties of
Ref
-like wrapper you have in mind?Current
Ref
IMHO is enough to allow separate evolution of field'sFormula
.Currently user may evolve schema and manually ensure desired compatibility.
I have the following plan to better support them:
Formula
s.Formula
. Then compatibility will be checked between versions. All in proc-macro execution time.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, not sure if I quite follow. If you serialize some data with
Ref<SomeTV1>
, add a field, then try to deserialize the old data withRef<SomeTV2>
, that will not work, right?It would be nice to have the ability to provide default values for fields added and then based on size of serialized data detect which fields are missing and fill them in.
You could also put another wrapper that is like
Lazy<Ref<T>>
where instead of filling in with default values, you could "attempt to get" the type at different versions, i.e. with different numbers of fields. Similar to "probe" types I made inprotoss
experiment forrkyv
: https://github.com/fu5ha/protoss/blob/master/protoss_test/src/derive.rs#L169-L173There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you would need to have defaults for new fields for backward compatibility.
For forward compatibility it would be enough to mark formula as non-exhaustive, so it would just skip fields added at the end.
How about
Lazy<AnyRef>
that can be viewed asLazy<AnyRef<T>>
.Where the only difference between
Ref<T>
andAnyRef<T>
is that binary format ofAnyRef
doesn't depend onT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe
Lazy
layer is not needed.This requires more work 🤣
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah exactly, I was thinking of making a single thing similar to what you propose that's like a hybrid.
Ideally it would still be typed based on the main type it represents "some version" of. Then
decode
would only let you ask for one of the known versions of that typeThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs more thinking about how exactly to integrate the deserialize and formula types/bounds but thats the basic vision I guess.