github.com/ipld/go-ipld-prime@v0.21.0/adl/rot13adl/rot13prototypes.go (about)

     1  package rot13adl
     2  
     3  // Prototype embeds a NodePrototype for every kind of Node implementation in this package.
     4  // This includes both the synthesized node as well as the substrate root node
     5  // (other substrate interior node prototypes are not exported here;
     6  // it's unlikely they'll be useful outside of the scope of the ADL's implementation package.)
     7  //
     8  // You can use it like this:
     9  //
    10  //	rot13adl.Prototype.Node.NewBuilder() //...
    11  //
    12  // and:
    13  //
    14  //	rot13adl.Prototype.SubstrateRoot.NewBuilder() // ...
    15  var Prototype prototype
    16  
    17  // This may seem a tad mundane, but we do it for consistency with the way
    18  // other Node implementation packages (like basicnode) do this:
    19  // it's a convention for "pkgname.Prototype.SpecificThing.NewBuilder()" to be defined.
    20  
    21  type prototype struct {
    22  	Node          _R13String__Prototype
    23  	SubstrateRoot _Substrate__Prototype
    24  }
    25  
    26  // REVIEW: In ADLs that use codegenerated substrate types defined by an IPLD Schema, the `Prototype.SubstrateRoot` field...
    27  // should it be a `_SubstrateRoot__Prototype`, or a `_SubstrateRoot__ReprPrototype`?
    28  //  Probably the latter, because the only thing an external user of this package should be interested in is how to read data into memory in an optimal path.
    29  // But does this answer all questions?  Codegen ReprPrototypes currently still return the type-level node from their Build method!
    30  //  This probably would functionally work -- we could make the Reify methods check for either the type-level or repr-level types -- but would it be weird/surprising/hard-to-use?