I'm going to share some thoughts here simply for discussion purposes - I
don't expect them to be directly applicable.
FWIW, protobuf-net has spoofed inheritance for many many years. I'm able to
do this because protobuf-net only needs to target .NET, which has good
inheritance support.
I don't really expect the main "protobuf" project will add inheritance in
any timescale, because it might need to target platforms that don't have
inheritance support.
It would also require ".proto" language considerations.
That said... if anyone at Google does ever want to reignite the discussion
around inheritance, I'm all ears :)
---
The way it protobuf-net does this can be *essentially* represented by
"oneof" - so going back to the original example from (wow, a long time ago):
message MSG1
{
required string account = 1;
required string symbol = 2;
}
message MSG2 extends MSG1
{
required int32 id = 2;
}
the way protobuf-net does this is essentially:
message MSG1
{
required string account = 1;
required string symbol = 2;
oneof _subtype { // keep in mind that this is actually "zero-or-one-of"
MSG2 msg2 = 3; // this field-number needs to be unique in MSG1
}
}
message MSG2
{
required int32 id = 2; // no restrictions on this field-number
}
but protobuf-net does some tricks so that when deserializing a MSG1, it
might end up *actually* creating an instance of MSG2 instead (where MSG2 :
MSG1).
For LSP purposes, everything is *always* serialized from the outside in, so
if you had a list/array of MSG2, they would still write the MSG1 fields
first - essentially
it would be like a list/array of MSG1, but where everything *happens to be*
an MSG2. You're right to say that the base type needs to know about the
derived types,
or at least have lib support to help it there, with some kind of deferred
registration.
But: I wonder whether the same approach - just without the actual
inheritance in the generated types - might still be useful to you.
Concretely, from a code-first angle:
https://gist.github.com/mgravell/a33755800e823ee77ba01183be7084df
Or maybe it is completely unhelpful and you're worse off for reading
this... who knows!
Marc
On Mon, 3 Sep 2018 at 11:34, SangemV <venkanna.san...@gmail.com> wrote:
> I see two problems with this approach. It is neither cut & paste nor
> personal preference issue as I see. The real issues I see are:
>
> 1) The base message (MSG in the example) and the extended message (MSG2
> in the example ) can belong to different package owned by different
> group/org. The package defining base message (MSG) (call it Pkg1) does not
> event know the existing of the package defining extended message (MSG2)
> (call it Pkg2). How can the base message foresee all the extended message
> from it? Even if Pkg1 and Pkg2 are owned by the same group/org, making Pkg1
> aware of Pkg2 is not a good idea as it can potentially create cyclic
> dependencies.
>
> 2) Polymorphic Lists: I have a list of MSG types which can potentially
> have both MSG and MSG2 types. How is this modeled in proto3 using the
> proposed solution?
>
> These are real issues which I am facing right now. Any suggestions to
> handle the above problems would be of great help.
>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>
--
Regards,
Marc
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
