feat: Introduce AccountCodeInterface and trait AccountComponentInterface#2924
Draft
PhilippGackstatter wants to merge 7 commits into
Draft
feat: Introduce AccountCodeInterface and trait AccountComponentInterface#2924PhilippGackstatter wants to merge 7 commits into
AccountCodeInterface and trait AccountComponentInterface#2924PhilippGackstatter wants to merge 7 commits into
Conversation
… helper Pulls the const-fn validator out of StorageSlotName into a new internal name_validation module so the same rules can be reused by an upcoming AccountComponentName type. StorageSlotName now delegates to the helper and exhaustively maps each internal error variant onto its StorageSlotNameError counterpart.
Introduces a validated newtype for canonical component names: - AccountComponentName: a Cow<'static, str>-backed newtype with a const fn from_static_str constructor (so hard-coded NAME constants can become typed names at compile time without runtime allocation) and a runtime fallible new() constructor. Display, FromStr, TryFrom, From-into-String are provided; PartialEq, Eq, Hash, PartialOrd, Ord are derived through Cow's content-based impls. - AccountComponentNameError: public error mirroring StorageSlotNameError, populated by an exhaustive map from the internal NameValidationError that was extracted in the prior commit. Validation is delegated to the shared name_validation helper, so the syntactic rules stay in lockstep with StorageSlotName.
Adds an inherent `pub const fn name() -> AccountComponentName` method to every leaf standard component, returning the canonical typed component name built via AccountComponentName::from_static_str(Self::NAME): - BasicWallet, FungibleFaucet, TokenPolicyManager - AuthSingleSig, AuthSingleSigAcl, AuthMultisig, AuthGuardedMultisig, NoAuth, AuthNetworkAccount - Ownable2Step, RoleBasedAccessControl - MintAllowAll, MintOwnerOnly, BurnAllowAll, BurnOwnerOnly Renames the existing FungibleFaucet::name(&self) -> &TokenName accessor to token_name() so the new associated AccountComponentName constructor can keep the canonical name() identifier.
Introduces the next-generation account-interface types:
- AccountComponentDependency: enum supporting both name-based static
dependencies (Name(AccountComponentName)) and procedure-root-based
dynamic dependencies (Procedure { description, root }).
- AccountCodeInterface: struct holding an account id and the set of
procedure roots exposed by an account, with a contains() helper. The
constructor enforces the [AccountCode::MIN_NUM_PROCEDURES,
AccountCode::MAX_NUM_PROCEDURES] range and returns
AccountCodeInterfaceError on violation.
- AccountComponentInterfaceV2: trait with Into<AccountComponent> as a
supertrait and a defaulted empty dependencies() method.
Account and PartialAccount each get an inherent code_interface() method
that produces the corresponding AccountCodeInterface. These are
infallible because the underlying AccountCode already enforces the
procedure-count invariant.
Each of the four new items (code_interface, component_interface,
dependency, name) lives in its own submodule of account::interface.
…ents Adds `impl AccountComponentInterfaceV2 for X` to every leaf standard component. Dependencies are wired per the design comment on the tracking issue: - FungibleFaucet -> Name(TokenPolicyManager) - RoleBasedAccessControl, MintOwnerOnly, BurnOwnerOnly -> Name(Ownable2Step) - TokenPolicyManager emits Procedure dependencies for its active and extra allowed mint/burn policy roots, exercising the dynamic dependency kind. TokenPolicyManager already implements IntoIterator<Item=AccountComponent>; adds a From<TokenPolicyManager> for AccountComponent that produces just the manager component to satisfy the trait's Into<AccountComponent> supertrait.
This file contains hidden or 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
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.
Introduces
AccountCodeInterfaceandtrait AccountComponentInterfaceas motivated in #2621.I renamed
AccountInterfacetoAccountCodeInterfacebecause it conceptually deals with the code of an account, so this seemed more precise and less generic.The dependencies of each component are implemented, but are not yet used by the
AccountBuilder, which would be done in another PR.The component interface is added as
V2and is intended to replace the existingAccountComponentInterfacein a future PR.One difficulty we encounter here is:
The interface requires
Into<AccountComponent>, but theTokenPolicyManageris an example of a component that does not implement it, because we use another pattern for constructing this component:impl IntoIterator for TokenPolicyManagerwhich yieldsAccountComponents. We would need an OR relationship here, either implement one or the other, but this is difficult to express.