-
Notifications
You must be signed in to change notification settings - Fork 111
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
SDK, reorganize mod structure for clarity #4749
Conversation
Moves a couple of utility functions from the root level into a pub channel and utils mod. Should make the docs a lot easier to read. Also aligns the crate file structure with its pub interface for clarity. This is technically a breaking change, but all moved functions are very new, and I don't expect teams to already be depending on them. And if they are, the compiler error message should make migration not too difficult.
Proposal: move all the mock attestation related stuff into This would leave the root (Honestly I'd probably move all the non-mock stuff to a different file as well, keeping only the interfaces in the root lib.rs file.) |
+1 all the mock stuff is quite invasive at the moment, a sub module may make that tidier |
I've moved the attestation structs to @tiziano88 @ipetr0v What do you both think? Imo this seems nice, but then the struct naming becomes a bit redundant. eg:
etc. Should we shorten the struct names? (imo probs yes). Should instead we keep it all in one mod? Many choices. |
I don't think we'll ever have a Group Attestation, so the instance attestation name may be confusing. So maybe just Also I think |
Idk, seems possible we may want that at some point
like public testing module? It needs to be public, since it's exported for to be used by other crates in their tests |
Moves a couple of utility functions from the root level into a pub channel and utils mod. Should make the docs a lot easier to read. Also aligns the crate file structure with its pub interface for clarity.
The diff is a bit misleading, but code has only been moved between files, not written anew.
This is technically a breaking change, but all moved functions are very new, and I don't expect teams to already be depending on them. And if they are, the compiler error message should make migration not too difficult.