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
From @daym:
Possible way to automate at least checking whether we forgot one here (steps):
Generate an enum with all the structs a la ElementRef--which we are already doing in the ondisk.rs for some of the items.
match here.
Maybe find out whether ElementAsBytes and/or SequenceElementAsBytes or the respective other traits are implemented for some struct and thus sanity-check this here.
Distinguishing those would be possible by using more specific macros than make_accessors, or adding an obvious parameter to make_accessors would could be seen by a macro that's called at the toplevel
and have record_structs match on patterns make_type1_accessors in one branch, make_type2_accessors in another branch (lazily--but that is how it is anyway), and result in one enum for all the type1, another enum for all the type2. Then use those.
Alternatively (and much less ugly), try using enum_dispatch.
From @GanShun:
I think I tried enum dispatch at one point, but it doesn't work with remote traits, so we'll need to find some way to work around that.
The text was updated successfully, but these errors were encountered:
From @daym:
Possible way to automate at least checking whether we forgot one here (steps):
Generate an enum with all the structs a la ElementRef--which we are already doing in the ondisk.rs for some of the items.
match here.
Maybe find out whether ElementAsBytes and/or SequenceElementAsBytes or the respective other traits are implemented for some struct and thus sanity-check this here.
Distinguishing those would be possible by using more specific macros than make_accessors, or adding an obvious parameter to make_accessors would could be seen by a macro that's called at the toplevel
record_structs! {
make_type1_accessors! {
struct Foo {
}
}
make_type2_accessors! {
struct Foo {
}
}
}
and have record_structs match on patterns make_type1_accessors in one branch, make_type2_accessors in another branch (lazily--but that is how it is anyway), and result in one enum for all the type1, another enum for all the type2. Then use those.
Alternatively (and much less ugly), try using enum_dispatch.
From @GanShun:
I think I tried enum dispatch at one point, but it doesn't work with remote traits, so we'll need to find some way to work around that.
The text was updated successfully, but these errors were encountered: