-
-
Notifications
You must be signed in to change notification settings - Fork 135
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
Provide support for specifying fields in output #376
Comments
That would certainly be nice to have! And it would even be backwards compatible. The implementation would probably have to use the schema information to build types to build a sibling structure like proposed here. I wonder if it could be made available through the returned structure itself. For instance, if |
The only obvious solution I can see that would allow for the proposed solution is using associated trait types: trait Fields {
type Fields;
}
struct File {
id: String,
name: String,
}
trait ToParam {
fn to_param(&self) -> String;
}
mod fields {
use super::ToParam;
pub enum File {
Id,
Name
}
impl ToParam for File {
fn to_param(&self) -> String {
match self {
File::Id => "id",
File::Name => "name"
}.to_string()
}
}
}
impl Fields for File {
type Fields = fields::File;
}
fn main() {
println!("{}", <File as Fields>::Fields::Id.to_param());
} This solution could use a separate module for the fields to avoid collisions wherever possible (the names can be further disambiguated by using the full method chain). Your proposal of using However, using the trait-based associated type approach would not prevent |
This looks good to me, and I think it would help tremendously to know exactly how to access a types fields, instead of associating them by naming scheme for example. The latter would of course work, too, i.e. In any case, my suggestion is to go ahead with a minimal implementation that associates field enums by name, and optionally associate the struct and enums by trait in a follow-up. |
It would be nice if the APIs provided an
include_field
API with definitions for fields that could be included. Given that all possible fields are known, it seems like it'd be possible to generate a field enum for each method, which includes all of the possible fields.This would be helpful for both discoverability (since this might not be the most well-known feature), and correctness (by only including fields which exist as enum variants, every
include_field
call would be correct, and we can guarantee that thefields
parameter syntax would be correct).Example usage (current):
Example usage (desired):
The text was updated successfully, but these errors were encountered: