Any <> interface Conversion

[aaronc]

This will reuse the existing cosmos_proto.implement_interface and cosmos_proto.accepts_interface: https://github.com/regen-network/cosmos-proto/blob/master/cosmos.proto

We want a mapping from proto interface names to golang interface names, ex:

interfaces:
  cosmos.gov.Content: github.com/cosmos/cosmos-sdk/x/gov/types.Content

Then the generated code should use the interface and not Any, ex:

type MsgSubmitProposal struct {
	Content        Content
	InitialDeposit []*Coin
	Proposer       string                                   
}

protoreflect.Message and fast marshaling handling will need to be generated

• bring in protoc bring in protoc-gen-go #23

• struct code gen

• protoreflection & proto methods

[technicallyty]

not sure if the protogen plugin library recognizes brackets to do stuff like string foo = 1 [(implements_interface: bar]);- https://pkg.go.dev/google.golang.org/protobuf/compiler/[email protected]#Field

One way around this is to use comments instead. each field gives us access to the comments attached to it either on top of it, or trailing it. so we could do stuff like:

string foo = 1; // @implements_interface: cosmos.gov.Content
or similarly

// @implements_interface: cosmos.gov.Content
string foo = 1; 

also, the type of the field on the message struct is generated by protoc-gen-go, so we'd have to manipulate the AST again to achieve this, or consider forking their plugin again

just out of curiosity, was using enums ever considered for the Any problem? judging by Interface Encoding and Usage of Any section of the docs, i feel, in the example, it could be more straightfoward to just have an Enum field with each account type as an option.

[aaronc]

There is a way to do it, you just need to dig into the API. From a quick glance I think it's Options(). We don't want to use comments.

Yes we will definitely need to manipulate the struct codegen. Maybe we can just override that part of the AST?

We did consider oneof's quite extensively and we're not going to open that can of worms again lol

[robert-zaremba]

@technicallyty the problem with enums / oneof is that it's closed for extensibility. If you add a new type which implements an interface X, then you need to re-generate any other type which depends on X.

[aaronc]

Seems like we can close as "won't fix" for now?