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
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
IMHO we have now reached the point where this should be abstracted. IMHO I don't see any point in copying this for every type in the std library (I know that we don't need every type). However this is mainly code copying. Which should be doable with some generic container or a macro that generates the stuff.
I don't have as strong opinion about BtreeMap and Set. On one hand they are types that we support in storage and we are a library, on the other hand we don't really use them (for good reasons) and we shouldn't overkill it. Either way I am happy with this PR.
About your comment on abstraction: I think what we do need is a next to our , because we have quite a few storage items that have the assumption that they must always be sorted. And implementation-wise I was thinking of something like this:
structAttributeVec<T,Attr:Attribute>(Vec<T>);/// An attribute to a container like a VectraitAttribute{fnpre_insert();fnpost_insert();fnpre_delete();fnpost_delete();// and some other hooks/utilities that allow an attribute to control how a container mutates.}/// An attribute that ensures a container's length never goes beyond a limit.structBounded;implAttributeforBounded{fnpre_insert(){/* ensure bound */}}/// An attribute that ensures a container is always sorted. structSorted;implAttributeforSorted{fnpost_insert(){/* do sort! */}fnpost_delete(){/* do sort! */}}// and we can have other attributes, and attributes can be combined by aggregating them into a tuple. #[impl_trait_for_tuples(18)]ifAttribute for Tuple{/* ... */}/// typeBoundedVec<T> = AttributeVec<T,Bounded>;typeSortedVec<T> = AttributeVec<T,Sorted>;typeBoundedSortedVec<T> = AttributeVec<T,(Bounded,Sorted)>;
But to be honest there are a lot of empty pieces in my brain dump above, and I am worried that this would add so much complexity that we would regret it and just go back to the simpler way of copy-pasta.
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.
stalebot
added
the
A5-stale
Pull request did not receive any updates in a long time. No review needed at this stage. Close it.
label
Jul 7, 2021
It's a cool abstraction, particularly if we can implement it to get some fancy storage maps (i.e. no more custom CountedStorageMap, SortedStorageMap, etc; just get the right attributes on it). That said, I don't really see it happening soon.
I don't have as strong opinion about BtreeMap and Set. On one hand they are types that we support in storage and we are a library, on the other hand we don't really use them (for good reasons) and we shouldn't overkill it. Either way I am happy with this PR.
About your comment on abstraction: I think what we do need is a next to our , because we have quite a few storage items that have the assumption that they must always be sorted. And implementation-wise I was thinking of something like this:
But to be honest there are a lot of empty pieces in my brain dump above, and I am worried that this would add so much complexity that we would regret it and just go back to the simpler way of copy-pasta.
Originally posted by @kianenigma in #8750 (comment)
I am not sure if this idea is feasible at all yet, but I think the idea of a built-in sorted vec is worthwhile.
A much easier idea is to implement the sorted vec independently, or just use a trusted community crate, if any.
The text was updated successfully, but these errors were encountered: