Add exported accessors for builders + reprbuilders
I'm not sure if I like these symbol names. Or rather, I don't,
but haven't decided on what would be preferable yet.
There's a couple of options that have come to mind:
- option 1
- `func {{ .Type.Name }}__NodeBuilder() ipld.NodeBuilder`
- `func {{ .Type.Name }}__ReprBuilder() ipld.NodeBuilder`
- option 2
- `func NewBuilderFor{{ .Type.Name }}() ipld.NodeBuilder`
- `func NewReprBuilderFor{{ .Type.Name }}() ipld.NodeBuilder`
- option 3
- `func (Builders) {{ .Type.Name }}() ipld.NodeBuilder`
- `func (ReprBuilders) {{ .Type.Name }}() ipld.NodeBuilder`
Option 3 would make 'Builders' and 'ReprBuilders' effectively reserved
as type names if you're using codegen. Schemas using them could use
adjunct config specific to golang to rename things out of conflict in
the generated code, but it's still a potential friction.
Option 2 would also have some naming collision hijinx to worry about,
on further though. Only Option 1 is immune, by virtue of using "__"
in combination with the schema rule that type names can't contain "__".
This diff is implementing Option 1. I think I'm partial to Option 3,
but not quite confident enough in it to lunge for it yet.
Putting more methods on the *concrete* types would also be another
interesting fourth option! These methods would ignore the actual
value, and typically be used on the zero value: e.g., usage would
resemble `Foo{}.ReprBuilder()`.
The upside of this would be we'd then have no package scoped exported
symbols except exactly the set matching type names in the schema.
However, the opportunities for confusion with this would be numerous:
we couldn't use the 'NodeBuilder' method name (because that's the
potentially-stateful/COW one), but would still be returning a
NodeBuilder type? Etc. Might not be good.
More to think about here in the future.
Signed-off-by: 
Eric Myhre <hash@exultant.us>
Showing
Please register or sign in to comment