Skip to content

[#889] Add `L1AddressOrAlias`

Diogo Castro requested to merge diogo/#889-l1-address-or-alias into master

Description

Problem: At the moment, if a CLI application wants to have an option that accepts an address or alias that could belong to either a contract or an implicit account, that option must be split in two. E.g., in morley and morley-client, the transfer command accepts --to-implicit and --to-contract.

This is a bit cumbersome when you have many such options, and you end up with 2 * n CLI options.

Solution:

Add an L1AddressOrAlias type:

  • Overload resolveAddress and resolveAddressMaybe to work not only with ImplicitAddressOrAlias and ContractAddressOrAlias, but also with L1AddressOrAlias.
  • The parser for L1AddressOrAlias accepts addresses/aliases for either a contract or an implicit account.
  • When an alias is associated with both a contract and an implicit account, the user must use the prefix contract:<alias> or implicit:<alias> to disambiguate. If they don't, resolveAddress and resolveAddressMaybe will both fail.
    The alias 'ambiguous-alias' is assigned to both:
      * a contract address: #{contractAmbiguousAddr}
      * and an implicit address: #{implicitAmbiguousAddr}
    Use 'contract:ambiguous-alias' or 'implicit:ambiguous-alias' to disambiguate.
  • If they use the wrong prefix, e.g. if they use implicit:my-alias but it turns out my-alias is only associated with a contract, resolveAddressMaybe will return Nothing, and resolveAddress will fail with a helpful message:
    Expected the alias 'contract:implicit-alias' to be assigned to an address of kind 'contract',
    but it's assigned to an address of kind 'implicit': #{implicitAddr}.

The parser for AddressOrAlias has also been extended to accept the implicit: and contract: prefixes.

NB: The precise behavior is fully specified in TestSuite.AddressOrAlias.

Related issue(s)

Resolves part of #889 (closed).

We'll need to refactor getAlias next.

Checklist for your Merge Request

Related changes (conditional)

  • Tests (see short guidelines)

    • If I added new functionality, I added tests covering it.
    • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
  • Documentation

    • I checked whether I should update the docs and did so if necessary:
    • I updated changelog files of all affected packages released to Hackage if my changes are externally visible.

Stylistic guide (mandatory)

Edited by Diogo Castro

Merge request reports