Interfaces for nested types with common structure

[Daniel Lepage]

Hi everyone,

I am trying to figure out if there's a good way to build a helper that can be used against different sets of nested types that have a common structure.

So, for example, say there are two libraries, `lib1` and `lib2` and both define types Foo, Bar, and Baz with:

type Foo struct { ... }

type Bar struct { ... }

func (b *Bar) GetFoo() *Foo { ... }

type Baz struct { ... }

func (b *Baz) GetBar() *Bar { ... }

But `lib1` and `lib2` both define different additional methods on some of these structs, so I can't just merge them into a single library.

I would like to write a helper function `HelperFn(baz ??)` such that I can call `HelperFn(&lib1.Baz{})` and also `Helperfn(&lib2.Baz{})`.

In a simple case, I can use generic interfaces:

type Foo interface {}

type Bar[FT Foo] interface {

  GetFoo() FT

}

type Baz[FT Foo, BT Bar[FT]] interface {

  GetBar() BT

}

func HelperFn[FT Foo, BarT Bar[FT], BazT Baz[FT, BarT]](baz BazT) {

  ...

}

However, AFAIK there is no way to get the compiler to infer these generics, so to call this I have to write e.g. `HelperFn[*lib1.Foo, *lib1.Bar](&lib1.Baz{})`.

The above is only a little inconvenient, but in my actual use case the two libraries are generated code containing over a thousand types in an enormous hierarchical tree, which shifts this from "a little inconvenient" to "totally unusable" - some helpers would require >1K type parameters.

What's the recommended way to do this in Go?

Thanks,

Dan Lepage

[Brian Candler]

On Tuesday, 6 December 2022 at 21:05:48 UTC dple...@google.com wrote:

I am trying to figure out if there's a good way to build a helper that can be used against different sets of nested types that have a common structure.

So, for example, say there are two libraries, `lib1` and `lib2` and both define types Foo, Bar, and Baz with:

type Foo struct { ... }

type Bar struct { ... }

func (b *Bar) GetFoo() *Foo { ... }

type Baz struct { ... }

func (b *Baz) GetBar() *Bar { ... }

But `lib1` and `lib2` both define different additional methods on some of these structs, so I can't just merge them into a single library.

It seems to me that lib1.{Foo,Bar,Baz} and lib2.{Foo,Bar,Baz} are completely different types.  They just happen to have similar names.

Hence I ask, what's the commonality that you're trying to expose?  If it's that both lib1.Baz and lib2.Baz have a GetBar() method, then that sounds like an interface - except if one returns a lib1.Bar and the other returns a lib2.Bar, then they are not the same interface at all, so you're back to "these are completely different types".  Is there something common in Foo ?

 

I would like to write a helper function `HelperFn(baz ??)` such that I can call `HelperFn(&lib1.Baz{})` and also `Helperfn(&lib2.Baz{})`.

Why not just have HelperFn1(lib1.Baz) and HelperFn2(lib2.Baz)?

Perhaps there is some point in your code where a variable could hold either a lib1.Baz or a lib2.Baz.  If so, what's the type of that variable?  And what's the helper function going to do with the value that you're passing in, which could be of either type?

Whilst you can use generics in the way you've shown to call GetBar() and GetFoo(), you can't use generics for accessing struct members, so everything would have to be done via methods - even reading or setting elements of {lib1|lib2}.Foo.  I think at the bottom there has to be *some* common interface.

How important is static type checking in this application? You could always just write HelperFn(interface {}) which does type assertions on its parameter.  Admittedly this is ugly:

https://go.dev/play/p/14vs2Ce7P42

[Daniel Lepage]

On Wed, Dec 7, 2022 at 4:39 AM Brian Candler <b.ca...@pobox.com> wrote:

On Tuesday, 6 December 2022 at 21:05:48 UTC dple...@google.com wrote:

I am trying to figure out if there's a good way to build a helper that can be used against different sets of nested types that have a common structure.

So, for example, say there are two libraries, `lib1` and `lib2` and both define types Foo, Bar, and Baz with:

type Foo struct { ... }

type Bar struct { ... }

func (b *Bar) GetFoo() *Foo { ... }

type Baz struct { ... }

func (b *Baz) GetBar() *Bar { ... }

But `lib1` and `lib2` both define different additional methods on some of these structs, so I can't just merge them into a single library.

It seems to me that lib1.{Foo,Bar,Baz} and lib2.{Foo,Bar,Baz} are completely different types.  They just happen to have similar names.

Hence I ask, what's the commonality that you're trying to expose?  If it's that both lib1.Baz and lib2.Baz have a GetBar() method, then that sounds like an interface - except if one returns a lib1.Bar and the other returns a lib2.Bar, then they are not the same interface at all, so you're back to "these are completely different types".  Is there something common in Foo ?

<snip> 

Why not just have HelperFn1(lib1.Baz) and HelperFn2(lib2.Baz)? 

  

My actual use case involves a code generator, where lib1 and lib2 (and possibly dozens of additional libraries) are all outputs of the same generator with slightly different arguments, generated by various different teams and therefore entirely outside of my control.

The generator in question reads a schema file and outputs a library of Go structs for all the data types defined by the schema. There are more than a thousand such data types; they have getters and setters for their attributes, and they're all nested in a giant tree, so e.g. code could call 

root := &lib1.Root{}

root.GetFoo().GetBar().GetBaz().GetQux().GetFleem().SetName("hello")

The problem is that various users of the code generator have their own schemas, which are generally made by taking a common standard schema and adding extra fields needed by whatever specific project the users are working on. So for example one project might add a .GetSpoo() method to the Foo type, while another adds GetAlias to Fleem, etc.

What I really want to do is be able to write a helper like:

package examplehelper

func SetFleemName(root ???, name string) {

    root.GetFoo().GetBar().GetBaz().GetQux().GetFleem().SetName(name)

}

such that any project can have its own generated library and can call `examplehelper.SetFleemName(root, "foo")` on a Root{} from their own generated library, as long as the Root has GetFoo(), the Foo has GetBar(), etc. down to the Fleem having a SetName(string).

This is technically possible with generics, but not practical, because it requires writing e.g.:

x := lib1.Root{}

helper.SetFleemName[*lib1.Fleem, *lib1.Qux, *lib1.Baz, *lib1.Bar, *lib1.Foo](x, "foo")

and in my real use case that list of type parameters would have more than a thousand types in it.

 

Right now I'm experimenting with whether it's reasonable to use code generation to solve this - a code generator could either just copy a helper library and replace all the imports with a specific generated library, or could build a generated-library-specific "bridge" library that defines a bunch of

var SetFleemName = generichelper.SetFleemName[*lib1.Fleem, *lib1.Qux, ...<a thousand more types>]

But there's a lot of overhead to having everything go through a generator, and it makes the code harder to read, harder to debug, and harder to use in IDEs. I am hoping that there's some Golang feature I'm just not aware of that would allow me to do this in the language itself, but I haven't been able to find one so far.

Thanks,
Dan

[Brian Candler]

Code generation is the only option I can think of, perhaps with a top-level generic function to dispatch to the correct instance:

https://go.dev/play/p/9nCZQsfOeyx

Unfortunately the compiler doesn't accept this:

func HelperFn[T interface{ *lib1.Baz | *lib2.Baz }](baz T) int {
    return baz.GetBar().GetFoo().Get()
}