-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Rename traits to remove T suffix #1535
Conversation
@@ -94,7 +94,7 @@ impl<T: Config, C: OfflineClientT<T>> TxClient<T, C> { | |||
params: <T::ExtrinsicParams as ExtrinsicParams<T>>::Params, | |||
) -> Result<SubmittableExtrinsic<T, C>, Error> | |||
where | |||
Call: PayloadT, | |||
Call: Payload, | |||
Signer: SignerT<T>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine, just thinking out loud, how would the following look?
- import
crate::tx::Signer
(not asSigner T
) - Use
<Call, Sign> where Sing: Signer<T>
?
But yea, we don't have to do it since we already have an OfflineClientT and OnlineClientT
to distinguish between concret impl and traits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohyeah, we do use the T pattern for OfflineClient
and OnlineClient
too don't we; I guess we are still not super consistent hehe. At least those traits are generally not supposed to be imported/used I guess!
Use <Call, Sign> where Sing: Signer?
I think that makes sense!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Nice one! 👍
In the end I went for a pattern like:
Where the static and dynamic types are mostly just aliases to the
DefaultX
concrete type.