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
Currently, our types models contain two versions of structs: UncheckedFoo and a Foo for each type. This setup is such that we can align with the original rosetta SDK spec.
However, in terms of code quality, and API usage, it leaves much desired.
I suggest we leverage a type state model.
Behind the scenes, the code will still be ugly, but the API usage should be vastly improved as all types will be unified to one struct.
💥 Proposal
Currently, our types models contain two versions of structs:
UncheckedFoo
and aFoo
for each type. This setup is such that we can align with the original rosetta SDK spec.However, in terms of code quality, and API usage, it leaves much desired.
I suggest we leverage a type state model.
Behind the scenes, the code will still be ugly, but the API usage should be vastly improved as all types will be unified to one struct.
For example:
The asserter module would then transform the
Unchecked
version to theChecked
version.The usage of
PhantomData
should be fine as it's a zero-sized type at the end of the day optimized out of the way by the compiler.The text was updated successfully, but these errors were encountered: