Change StorageType to Just Be An Enum #873
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Corresponding XDR change: stellar/stellar-xdr#118 |
|
@dmkozh and/or @sisuresh I ran out of time this evening updating this PR to the changes in the XDR (and the last bunch probably need additional eyes from someone who knows more of what the intended semantic changes are, I was somewhat guessing). Feel free to pick up and extend this with the remainder if you get to it before me, otherwise I'll pick up tomorrow. |
sisuresh
force-pushed
the
storagetype-is-just-an-enum
branch
from
d9f9a0d to
253d03a
Compare
jayz22
approved these changes
Jun 22, 2023
sisuresh
approved these changes
Jun 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes
StorageTypeto just be a plain Rust enum (rather than aValwrapper) in preparation for removal ofStorageTypefromScVal.It also includes a change expanding
StorageType(the type at the env-interface layer) from 2 cases to 3 -- including::Instance-- deviating a bit fromContractDataType(the type that controls the storage layer). It includes a projection down to that lower layer type though.This PR isn't 100% complete, it depends on some more changes incoming at the XDR level -- and it appears it's going to have to integrate a bunch of pending XDR changes from other work -- but I thought I'd post it for examination. I think it's not too bad a solution to the problem. We still get to use
StorageTypeinenv.jsonand we get a strong enum type on both sides of the interface. We just ignore / bypassValentirely.