Skip to content

[#759] Make it easier to have consistent field naming between HasAnnotation and TypeHasDoc

Nikolay Yakimov requested to merge lierdakil/#759-typehasdoc-hasannotation-consistency into master

Note: while at it, I took the opportunity to refactor Lorentz.Util.TH a fair bit.

Description

Problem:

  • TypeHasDoc strips record field prefixes by default, while HasAnnotation doesn't.
  • Morley.Michelson.Typed.Haskell.Doc.haskellRepStripFieldPrefix, which is used to strip prefixes in TypeHasDoc, and Lorentz.Annotation.dropPrefixThen use different algorithms for dropping the prefix.

Solution:

  • Move all casing manipulation to Morley.Util.Text
  • Use new casing manipulation functions everywhere
  • Introduce TypeHasFieldNamingStrategy -- a typeclass with a catchall overlappable instance, which defines the strategy to use. Strategy being a function Text -> Text modifying field names. Require this typeclass in the default implementations of typeDocHaskellRep and annOptions. Apply the strategy as appropriate.
  • Add an optional field to typeDoc which allows specifying the strategy.

Discussion points:

  • Versions of toCamel, toSnake and toSpinal provided by Morley.Util.Text have behaviour differing from the old functions of the same name in some corner cases. While this behaviour is arguably "better" for our use case, it might introduce breaking changes to contract field names. I really want to have some sane handling of uppercase clusters, but I'm open to suggestions on how to improve the migration story here.
  • The default strategy is id. This is the previous default for HasAnnotation, however TypeHasDoc tried stripping the prefix in a pretty ad-hoc way. The net result is however we slice it, we'll have to change the default somewhere. I've opted to change the default on TypeHasDoc as it seems to be the lesser evil. #550 is relevant here.

Related issue(s)

Resolves #759 (closed)

✅ 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 Nikolay Yakimov

Merge request reports