Skip to content

Draft: [#894] Add AddressAndAlias datatype

Markus Barenhoff requested to merge alios/#894-address-or-alias into master

Description

This is an unfished branch addressing #894 (closed).

The basic idea of #894 (closed) is to add a new type AddressAndAlias :: (Address, Maybe Alias) which represents an address where an atemp to resolve the Address to an Alias has been already tried and was successfull or not (the Maybe). This should unify the API not having attemps to do alias resolution (back and forth) in different places all over the code base.

In this branch I added the type(s) and started to recfactor through the code base to make use of it, but to be honest I was not very happy with it so far for the following reasons:

We have a very similar type (actualy with an identical constructor: Adrress + Maybe Alias) AddressOrAlias which has a little bit different semantic (Its either and Address or an (Just) Alias where an alias could be "unknown" -> Nothing). In practice it leads to numerours namespace classes for record fields / lenses etc and is currently only circumvented by prefixes likeaaaSomething in case of an AddressAndAlias vs aoaSomething in case of an AddressOrAlias.

In general it felt more and more that instead of adding a new type to the Address and Alias modules in tezos it needs unification/simplicication - which I think was the original idea of the #894 (closed). (Check also the discussion here to get deeper into context)

The current branch definitly needs some work:

  • "refactor through" the AddressAndAlias type through the API(s) which haven't been touched yet
  • come up with good namings or type classes to work with the types (instead of having prefixed function names all over the place)

But maybe its time to rethink the topic again and/or with fresh eyes, use this branch as reference which parts need to be touched and then start fresh.

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 Markus Barenhoff

Merge request reports