github.com/ipld/go-ipld-prime@v0.21.0/node/mixins/HACKME.md (about)

     1  node mixins and how to use them
     2  ===============================
     3  
     4  These mixins are here to:
     5  
     6  1. reduce the amount of code you need to write to create a new Node implementation, and
     7  2. standardize a lot of the error handling for common cases (especially, around kinds).
     8  
     9  "Reduce the amount of code" also has an application in codegen,
    10  where while it doesn't save any human effort, it does reduce GLOC size.
    11  (Or more precisely, it doesn't save *lines*, since we use them in verbose style,
    12  but it does make those lines an awful lot shorter.)
    13  
    14  Note that these mixins are _not_ particularly here to help with performance.
    15  
    16  - all `ErrWrongKind` error are returned by value, which means a `runtime.convT2I` which means a heap allocation.
    17    The error paths will therefore never be "fast"; it will *always* be cheaper
    18    to check `kind` in advance than to probe and handle errors, if efficiency is your goal.
    19  - in general, there's really no way to improve upon the performance of having these methods simply writen directlyon your type.
    20  
    21  These mixins will affect struct size if you use them via embed.
    22  They can also be used without any effect on struct size if used more verbosely.
    23  
    24  The binary/assembly output size is not affected by use of the mixins.
    25  (If using them verbosely -- e.g. still declaring methods on your type
    26  and using `return mixins.Kind{"TypeName"}.Method()` in the method body --
    27  the end result is the inliner kicks in, and the end result is almost
    28  identical binary size.)
    29  
    30  Summary:
    31  
    32  - SLOC: good, or neutral depending on use
    33  - GLOC: good
    34  - standardized: good
    35  - speed: neutral
    36  - mem size: neutral if used verbosely, bad if used most tersely
    37  - asm size: neutral