Added well-known types generated by vtproto plugin

[biosvs]

Another approach that was discussed in a comments to #80.

The idea is to generate wkt using the same plugin (vtProto) and to store generated code in the same repo.

From developers perspective, to use these pre-generated code they have to:

1. Extend protoc arguments with imports replacements.
2. Change import paths in a source code.

The same information added to readme. Please find example of usage in an added unit tests.

(There are more wkt in original probouf repo, but I skipped those are made for internal usage - those are describing protobuf implementation itself like types, structure, descriptor, etc.)

[biosvs]

I think we have to make some decision regarding well-known types.

сс @nockty @vmg

[vmg]

I agree. I spent some time this morning looking at the two existing PRs. My order of preference would be:

1. Custom serialization functions exposed in the vtprotobuf package as free-standing functions (i.e. not methods, because we can't do methods) that get automatically called by the generated code. This hasn't been implemented yet.

   • 🟢 Efficient from a code-generation standpoint
   • 🟢 Transparent to the user, works automatically
   • 🔴 We don't get to (de)serialize unknownFields

2. Custom types with aliases (this PR, Added well-known types generated by vtproto plugin #93)

   • 🟢 Efficient from a code-generation standpoint
   • 🟢 Supports unknownFields
   • 🔴 Annoying set-up step during compilation
   • 🔴 Not transparent: types have been changed

3. Custom in-line generation (External well-known structures support #80)

   • 🟢 Transparent to the user, works automatically
   • 🔴 We don't get to (de)serialize unknownFields
   • 🔴 Inefficient from a code-generation standpoint

IMO I really don't see an issue with not supporting unknownFields. The WKTs have been frozen for years and they are not going to change anytime soon. They won't show up on the wire with extra fields. I think as long as we state this limitation explicitly, approach (1) is by far the most ergonomic.

I'm gonna spend some time today implementing it. Can somebody point out a shortcoming of (1) that I missed?

[nockty]

Thanks for moving the discussion forward and thanks a lot for providing an implementation @biosvs!

My two cents: I think I tend to prefer something like approach (1) as well because, in my opinion, the simplicity of using basic features of vtprotobuf is a major selling point. Currently, you just have to easily generate code and change a couple calls (proto.Unmarshal(...) => message.UnmarshalVT(...)) and it just works, which I think is a valuable trait and something worth trying to keep (for basic features).

[biosvs]

I'm okay with that approach (to hide implementation inside generated code).

But I want to be sure we're on the same page: (Un)MarshalVT functions for wkt should be pre-generated and placed in the vtProto repo, so, we're still adding vtProto repository as a hard dependency to projects that are using vtProto and wkt, right?

[vmg]

Yes, that would be the case. I'll definitely add an optional flag to fallback to reflection-based methods for people who don't want the dependency.

[biosvs]

Let's then have an overview of proposed changes.

Features management and code quality

Two new features were mentioned:

1. Add new flag for generating standalone functions - with different signature and different unknownFields handling (as code for well-known types itself should be generated somehow).
2. Add new flag to specify marshal/unmarshal methods for wkt (native reflection vs pre-generated code).

Does someone have ideas how to manage it without additional levels of if's in code (there are enough of them already)?

Interaction between standalone functions

How should interact (un)marshal and size functions, for example? I mean, now it's done as follows:
if _, ok := m.(interface{SizeVt() int}); ok
With a standalone function it's more complicated (if feasible).

Other existing features

There are more features: like clone, equal, pool, size. Should standalone functions feature be implemented for them too?