Embedded types are not migrated

[unmultimedio]

Hello, if I have a generated type embedded in another type, the tool does not recognize it for migration:

type MyFoo struct {
  *foopkg.GeneratedFoo // proto generated, let's say it contains field "bar"

  // some additional fields
}

I expect:

  var f MyFoo
- f.Bar = "bar"
- bar := f.Bar
+ f.SetBar("bar")
+ bar := f.GetBar()

But the tool does not recognize MyFoo as a type that needs migration.

[stapelberg]

Hey @unmultimedio, thanks for filing this issue.

Yes, embedded types are currently not recognized by the open2opaque tool.

Inside Google, we recommend against embedding protobuf generated message types into a struct. It’s an error-prone pattern, because then your struct implements the proto.Message interface by forwarding to the embedded message, which only knows about part of the struct it’s embedded in. So, for example, code which uses Go Protobuf reflection to compare two messages for equality would only operate on the proto message fields, not your additional fields.

We recommend naming the struct field, i.e.:

type MyFoo struct {
  Foo *foopkg.GeneratedFoo
  // some additional fields
}

For now, I recommend doing this refactoring first and then reaching for open2opaque.

If many people encounter this issue, we can see about implementing support for it (please use the thumbs up vote on the first comment of this issue to signal you also ran into the issue).

[unmultimedio]

Thanks for your reply, I'll take a look to see if we can easily do that refactor to run the migration tool again.

Quite similarly, just realized that types definitions and aliases based off generated types have this same issue:

type MyFooT foopkg.GeneratedFoo
type MyFooA = foopkg.GeneratedFoo

Then I'd expect both types to be recognized for migration, but they're not. Should this be a separate issue?

[stapelberg]

Hello again and happy new year!

type MyFooT foopkg.GeneratedFoo

This is also an anti-pattern:

A Go type that binds another named type possesses the underlying representation of the type (i.e., its memory layout), but not the behavior of the type (i.e., its method set). This is problematic for dynamic packages such as cmp that need to interrogate arbitrary types using Go reflection. This form of type declaration hides type information about the underlying protobuf message from Go reflection.

My suggestion is to eliminate this pattern from your code base.

type MyFooA = foopkg.GeneratedFoo

Type aliases on the other hand should probably work. Can you file a feature request for supporting type aliases please?

[unmultimedio]

Thanks for the reply and recommendations, and happy new year to you too! filed the alias feature request here #11

Closing this one one.