Protobuf is really missing inheritance

[zatziky]

What language does this apply to?
proto3 OR proto-future

Describe the problem you are trying to solve.
Lot's of DRY code in statically typed languages.

Describe the solution you'd like
I'd like you to add inheritance to current proto3 or at least the future protobuf versions. An example is:

message Parent { }

message ChildA extends Parent { }
message ChildB extends Parent { }
message ChildC extends Parent { }

Alternatives you've considered
I know about composition and it's really not a cure.

Additional context
I know that protobuf favors composition over inheritance but it's really not a cure to remove inheritance completely. Statically typed languages like Java or C# suffer from composition only approach. These languages cannot use polymorphism because all the messages have the same parent GeneratedMessageV3. If inheritance was available, we could use polymorphism. Instead of having to write:

void method(ChildA arg)
void method(ChildB arg)
void method(ChildC arg)

we could simply write void method(Parent arg). Consequently, the missing inheritance generates a lot of DRY code is hardly or not at all DRYable. It leads to wider test suites that take more time to execute. I could go on but I hope I explained myself. (If not, just ask and I'll clarify it.)

[perezd]

FWIW

To quote the Protocol Buffers tutorial:
"Don't go looking for facilities similar to class inheritance, though – protocol buffers don't do that."

Instead of inheritance, Protocol Buffers tends to favor composition as a pattern.

[zatziky]

@perezd

GRPC is not doing "favor composition over inheritance" pattern, it's applying "remove inheritance" pattern. :D

There are cases when inheritance is more suitable. Just because it's a good practice to "favor somehing", it doesn't mean it should be removed completely (or not implemented at all).

Real life example

Favor public transport over driving a car when going to work

Yes, most of the time we should use public transport because it's better for Earth. On the other hand, you have cases when driving a car is a better option, e.g. if there is no public transport in your surroundings.

[ObsidianMinor]

How are you supposed to implement inheritance in a language that doesn't support inheritance like Rust or Go which only support struct-like data types?

[TeBoring]

For proto3, use Any.
For proto2, user extension.

[weitzhandler]

I want to have a base type for all server messages, request and response, then I want to have different types of requests/responses.
Anyone has experimented with this idea and found any adequate way to implement that?

[vphantom]

I want to have a base type for all server messages, request and response, then I want to have different types of requests/responses. Anyone has experimented with this idea and found any adequate way to implement that?

For one project I did something like this to minimize redundancy:

message Request {
  uint64 magic = 1;  // Optional unique identifier for this request
  oneof _Request_oneof {
    ProfileRequest     profile_request     = 3;
    // ...other kinds of requests
  }
}

message Response {
  uint64 magic = 1;  // Your optional unique identifier echoed back so you may match our responses with your requests
  oneof _Response_oneof {
    string              error                = 2;  // Defined instead of your expected response below, on failure
    ProfileResponse     profile_response     = 3;
    // ...other kinds of responses
  }
}

message Message {
  // ... auth stuff
  repeated Request  requests       = 4;
  repeated Response responses      = 5;
  string            status         = 6;  // Protocol-level status or error message
}

So a Russian doll, basically: a Message is what's always on the wire, each can contain any number of requests and responses (they're multiplexed by magic ID to minimize the number of distinct messages being exchanged), then in the Request and Response I point to the specific one it represents. For example a ProductRequest might request the details of a product by ID and the ProductResponse would contain a Product, etc.