You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
messageMyServiceResponse {
messageSuccess {
// This is just one example, the Success message could in principle hold anythingoneofstatus {
Donedone=1;
Skippedskipped=2;
}
}
oneofresult {
Successsuccess=1;
InvalidRequestinvalid_request=2;
InternalErrorinternal_error=3;
NotFoundnot_found=4;
}
}
messageInvalidRequest {
stringerror=1;
}
messageInternalError {
stringerror=2;
}
messageNotFound {}
messageDone {}
messageSkipped {}
prost_build takes this and generates something like this:
#[allow(clippy::derive_partial_eq_without_eq)]#[derive(Clone,PartialEq,::prost::Message)]pubstructMyServiceResponse{#[prost(oneof = "my_service_response::Result", tags = "1, 2, 3, 4")]pubresult:::core::option::Option<my_service_response::Result>,}pubmod my_service_response {#[allow(clippy::derive_partial_eq_without_eq)]#[derive(Clone,PartialEq,::prost::Message)]pubstructSuccess{#[prost(oneof = "success::Status", tags = "1, 2")]pubstatus:::core::option::Option<success::Status>,}pubmod success {#[allow(clippy::derive_partial_eq_without_eq)]#[derive(Clone,PartialEq,::prost::Oneof)]pubenumStatus{#[prost(message, tag = "1")]Done(Done),#[prost(message, tag = "2")]Skipped(Skipped),}}#[allow(clippy::derive_partial_eq_without_eq)]#[derive(Clone,PartialEq,::prost::Oneof)]pubenumResult{#[prost(message, tag = "1")]Success(Success),#[prost(message, tag = "2")]InvalidRequest(InvalidRequest),#[prost(message, tag = "3")]InternalError(InternalError),#[prost(message, tag = "4")]DocumentNotFound(NotFound),}}
Constructing an instance of MyServiceResponse is unfortunately quite tedious:
let response = MyServiceResponse{result:Some(my_service_response::Result::Success(
my_service_response::Success{status:Some(my_service_response::success::Status::Done(Done{},)),},)),};
That's quite a deep level of nesting where the only actual field comes at the end.
Therefore I've taken to writing methods like this:
Which lets me construct responses much more concisely. However, writing this function is still quite tedious, especially if there's a lot of messages like this.
At first, I thought I could fix this myself, but I don't see any way to generate these functions based only on the resulting Rust code (i.e. by writing a macro) as that would require knowledge of multiple types at once. At least it seems very difficult.
I'm wondering if prost-build could somehow automatically generate constructors like this? I could imagine it would make construction of messages a lot easier, not just for this specific message but for messages in general. Basically the idea would be to generate this kind of function for messages that only have one field, and if that one also only has one field, then take the input as that field (and recursively etc.). Hope that makes sense.
The text was updated successfully, but these errors were encountered:
I believe builders (#399) can deliver some convenience, by eliminating the layer of Option for the oneof value. Constituent message fields can in turn be initialized with a builder. I've got #901 open to optionally generate builder APIs for messages.
I have a lot of protobuf messages like this:
prost_build takes this and generates something like this:
Constructing an instance of
MyServiceResponse
is unfortunately quite tedious:That's quite a deep level of nesting where the only actual field comes at the end.
Therefore I've taken to writing methods like this:
Which lets me construct responses much more concisely. However, writing this function is still quite tedious, especially if there's a lot of messages like this.
At first, I thought I could fix this myself, but I don't see any way to generate these functions based only on the resulting Rust code (i.e. by writing a macro) as that would require knowledge of multiple types at once. At least it seems very difficult.
I'm wondering if
prost-build
could somehow automatically generate constructors like this? I could imagine it would make construction of messages a lot easier, not just for this specific message but for messages in general. Basically the idea would be to generate this kind of function for messages that only have one field, and if that one also only has one field, then take the input as that field (and recursively etc.). Hope that makes sense.The text was updated successfully, but these errors were encountered: