-
Notifications
You must be signed in to change notification settings - Fork 432
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
Hide collection
and lazy
modules
#1111
Conversation
These use types from `collections` which are not available publicly anymore.
It doesn't looks like there's a way to keep these compiling if we're hiding the collection module, so the next best thing to do is to remove them completely.
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 agree that we should be able to hide/remove the storage alocator. I think you need to make the CI happy in order to get our change break down (gas/size), right? Or is this still broken from the storage deposit fallout? @cmichi
@@ -62,9 +68,13 @@ mod test_utils; | |||
|
|||
#[doc(inline)] | |||
pub use self::{ | |||
alloc::Box, | |||
lazy::Mapping, | |||
memory::Memory, |
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.
Do we really need this? It feels like an anti pattern to make use of this. Data should be passed as an argument where possible IMHO. Also, I think supporting this in the future will be annoying.
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.
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 strong opinion here. I have a bad feeling about not having any example using this though. In consequence we don't have any proper on-chain ink-waterfall
test for it either.
Data should be passed as an argument where possible IMHO.
Agree, but I don't know enough about why it was introduced in Solidity in the first place.
Does @ascjones know more?
There was an issue with GitHub access tokens that got fixed a couple days ago. I'm just gonna re-run the CI and it should post it |
🦑 📈 ink! Example Contracts ‒ Changes Report 📉 🦑These are the results when building the
Link to the run | Last update: Wed Feb 2 02:13:45 CET 2022 |
crates/lang/macro/src/lib.rs
Outdated
/// # // doesn't compile. | ||
/// # // | ||
/// # // On a sidenote, I think that with the removal of the `collections` module we'll be able | ||
/// # // to get rid of all the dynamic storage allocation infrastructure. |
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.
Just put all of this into an issue.
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.
Yep made #1120
Why is it necessary to remove |
Because of the interaction with |
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 you move the comments into individual GitHub issues I'm fine with it. It's super-sad that we have to hide those collections for the moment, but we can always bring them back in later versions.
Codecov Report
@@ Coverage Diff @@
## master #1111 +/- ##
===========================================
+ Coverage 63.69% 78.82% +15.12%
===========================================
Files 252 252
Lines 9395 9397 +2
===========================================
+ Hits 5984 7407 +1423
+ Misses 3411 1990 -1421
Continue to review full report at Codecov.
|
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.
Yeah let's keep Memory
around for now. We can always remove it later since it doesn't touch storage.
* Hide top level `collections` and `lazy` modules * Ignore failing doc-tests These use types from `collections` which are not available publicly anymore. * Stop using `Lazy` in `ERC-20` example * Use `Mapping` re-export in `ERC-721` example * Update UI tests to match updated examples * Allow `dead_code` in `lazy` and `collections` modules * Remove `Box` and `Pack` from top level `ink_storage` re-exports * Stop using `Lazy` in `multisig` example * Remove `Lazy` usage from DNS example * Update path of `Mapping` in `ERC-1155` example * Stop using `Lazy` in `trait-erc20` example * Undo changes to `alloc` tests * Add TODOs noting why we're ignoring certain doctests * Remove references to `storage::Box` from doc comments * Stop re-exporting `boxed::Box` * Remove storage collection benches It doesn't looks like there's a way to keep these compiling if we're hiding the collection module, so the next best thing to do is to remove them completely. * Remove `Lazy` from `delegator` example * Appease Clippy * Mention tracking issue for code removal instead of blank TODO
The goal of this PR is to begin the process of removing all data structures other than
Mapping
from the publicink!
API. We're starting by just hiding thecollections
andlazy
modules from users. Eventually we'll want to remove the code entirely, but Iwanted to make the minimal amount of changes required to get this compiling.
Rational
You may be asking: why remove all our great collections? Well, if you've noticed a theme
in
ink!
over the last few months its been that of reducting complexity in order toreduce the size of contracts. This takes another step towards that.
Until we can provide full-featured collections which don't bloat contract sizes the only
reasonable step forward to (somewhat strongly) encourage developers to use
Mapping
astheir main "data type".
Eager Loading
One consequence of this PR is that because there is no more
Lazy
type, every singlestorage item from your contract will be loaded from storage eagerly. To give a more
concrete example, consider the following contract storage struct:
In this case every time we execute the contract we'd load up the entire
Vec
fromstorage (even if we didn't use the
Vec
during the execution). For largeVec
thiswould be inefficient, but it's something you as a developer will need to be mindful of
going forward.
Compatibility
Unfortunately, this will be a breaking change for any contract using collections
other than
Mapping
. If your contracts were mainly just usingHashMap/BTreeMap
themigration should be pretty straightforward - although during the migration you will
notice that the API for
Mapping
is more rudamentary (by design) than the latter twodata structures.
Follow-Ups
PRs.
XYZ
as the issue numbers. Once I make those issues I'llupdate the PR to fill them in.
we can get rid of the dynamic storage allocator code entirely. Someone correct me if
I'm wrong here.
ink!
and external (such as on our docsportal) that will need to be updated
ink_lang::codegen::initialize_contract()
for initializingMapping
'sRelated issue: #996