-
Notifications
You must be signed in to change notification settings - Fork 67
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
look through references to improve externally tagged enum
generation
#178
Comments
In that specific case, I think we could generate better code if we picked apart the referenced #[derive(Clone, Debug, Deserialize, Serialize)]
pub enum AlignValueVariant0ItemSubtype1Subtype1Subtype0 {
Signal(String),
Value(AlignValueVariant0ItemSubtype1Subtype1Subtype0Variant1Value),
Field(Field),
Range(AlignValueVariant0ItemSubtype1Subtype1Subtype0Variant3Range),
} This uses the default The downside (such as it is) is that this would no longer use the impl TryFrom<AlignValueVariant0ItemSubtype1Subtype1Subtype0> for SignalRef {
type Error = &'static str;
fn try_from(value: AlignValueVariant0ItemSubtype1Subtype1Subtype0) {
match value {
AlignValueVariant0ItemSubtype1Subtype1Subtype0::Signal(signal) => Ok(Self { signal }),
_ => Err("nope!"),
}
}
} What do you think? Internally I think we'd do something like annotating each variant's IR to say "this is actually a type that we picked apart so offer up a |
The vega spec also seems to have many duplicated structures that might be nice to consolidate, though that would require us to figure out an appropriate name for the type. The current naming is, effectively, path dependent, and while not the nicest at least is simple to construct. |
enum
generation
This turns out to be quite a pain in the neck right now. It may need to wait for #195 (in particular see "Separate mutable and immutable structures") |
We currently "expand" or "look through" referenced types for internally tagged enums, but don't for externally tagged enums. There is more we could do to be clever in both cases. We want to preserve types rather than expanding them, but there's also some opportunities to do a better job of naming enum variants. This kicked over some inconsistencies and accidents with varied use of `get_object` and `schema_is_named` So far this has cleaned up some grotty code, but there's more we can do to tidy it up.
Another idea: #[derive(Clone, Debug, Deserialize, Serialize)]
pub enum AlignValueVariant0ItemSubtype1Subtype1Subtype0 {
Value(AlignValueVariant0ItemSubtype1Subtype1Subtype0Variant1Value),
Field(Field),
Range(AlignValueVariant0ItemSubtype1Subtype1Subtype0Variant3Range),
#[untagged]
SignalRef(SignalRef),
} |
This is a possible solution to some of the gnarly Vega code generation. Several of the more complex types end up with many
VariantN
layers (like @ahl mentioned in #165).For example we have:
It might be okay to replace instances of that enum with something like
Box<dyn AsVegaAlign>
.The text was updated successfully, but these errors were encountered: