-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
srml/session/src/lib.rs
Outdated
} | ||
|
||
fn clear_key_owner(id: KeyTypeId, key_data: &[u8]) { | ||
<KeyOwner<T>>::remove(DEDUP_KEY_PREFIX, &(id, key_data.to_vec())); | ||
<KeyOwner<T>>::remove(&DEDUP_KEY_PREFIX, &(id, key_data.to_vec())); |
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.
<KeyOwner<T>>::remove(&DEDUP_KEY_PREFIX, &(id, key_data.to_vec())); | |
<KeyOwner<T>>::remove(&DEDUP_KEY_PREFIX, &(id, key_data)); |
This file is actually the reason I started with EncodeLike
:D
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.
done, and tried to catch up most of them
also maybe I could check for compile time regression, EDIT: I didn't make a proper full check but seems fine |
@@ -929,7 +929,7 @@ impl<T: Trait> Module<T> { | |||
} else { | |||
<DispatchQueue<T>>::append_or_insert( | |||
now + info.delay, | |||
[Some((info.proposal, index))].into_iter() | |||
&[Some((info.proposal, index))][..] |
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 that makes no real difference, but okay.
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.
no it will compile with something like:
the trait bound `Iter<'_, std::option::Option<(<T as Trait>::Proposal, u32)>>: EncodeLike<std::vec::Vec<std::option::Option<(<T as Trait>::Proposal, u32)>>>` is not satisfied
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.
hmm at some point we should derive EncodeLike for standard iterator structures.
@@ -816,7 +816,7 @@ impl<T: Trait> Module<T> { | |||
if set_len + 1 == VOTER_SET_SIZE { | |||
NextVoterSet::put(next + 1); | |||
} | |||
<Voters<T>>::append_or_insert(next, [Some(who.clone())].into_iter()) | |||
<Voters<T>>::append_or_insert(next, &[Some(who.clone())][..]) |
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.
You are still cloning.
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.
yes because satisfying both iterator constrained and EncodeLike<Vec<T>>
is hard.
@@ -839,13 +840,17 @@ mod test_append_and_len { | |||
#[test] | |||
fn append_or_put_works() { | |||
with_externalities(&mut TestExternalities::default(), || { | |||
let _ = MapVec::append_or_insert(1, [1, 2, 3].iter()); | |||
let _ = MapVec::append_or_insert(1, [4, 5].iter()); |
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.
Shouldn't this work as well?
Co-Authored-By: Bastian Köcher <bkchr@users.noreply.github.com>
@@ -159,7 +159,7 @@ decl_module! { | |||
let id = Self::next_asset_id(); | |||
<NextAssetId<T>>::mutate(|id| *id += One::one()); | |||
|
|||
<Balances<T>>::insert((id, origin.clone()), total); | |||
<Balances<T>>::insert((id, &origin), total); |
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.
cc @shawntabrizi in v2 for kitties tutorial: the original issue of the PR references the v2 tutorial. If keys of type tuple are still around they can be refactored now
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.
awesome!
let new_prop = (index, (*proposal).clone(), who); | ||
<PublicProps<T>>::append_or_put([new_prop].into_iter()); | ||
let new_prop = (index, proposal, who); | ||
<PublicProps<T>>::append_or_put(&[Ref::from(&new_prop)][..]); |
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.
If can be refactored and you think it is worth it, would be good to have a small issue for it after the PR is merged 👍
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.
Ref from inside srml-support/storage/generator like in the implementation of linkedmap and map.
here it is legit. no super beautiful indeed.
// Next element key in storage (None for the last element) | ||
next: Option<NKey>, | ||
// The key of the linkage this type encode to | ||
phantom: core::marker::PhantomData<Key>, |
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.
import from rstd for consistency?
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 will revisit this at a later point since I could not read some parts in detail; looks to be already great.
Fix #1876
Done:
Critics:
I think we could do refactoring of this in a following PR