Re: [protobuf] Inheriting protobuf messages
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 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.
Re: [protobuf] Inheriting protobuf messages
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.
>
On Friday, October 21, 2016 at 1:42:36 AM UTC+5:30, Marcelo Cantos wrote:
>
> It probably wouldn’t be difficult to implement, but it’s not, afaik, a
> design goal for protocol buffers because it is almost never (if ever)
> necessary.
>
> There are two composition approaches available, depending on what your
> needs are. Contain the common stuff:
>
> message Common {
> required string account = 1;
> required string symbol = 2;
> }
> message MSG1 {
> required common = 1
> }
> message MSG2 {
> required common = 1
> required int32 id = 2;
> }
>
> Or contain the variable stuff:
>
> message MSG {
> required string account = 1;
> required string symbol = 2;
> optional Extra1 extra1 = 3;
> optional Extra2 extra2 = 4;
>
> message Extra1 {
> required int32 id = 1;
> }
>
> message Extra2 {
> required string foo = 1;
> }
> }
>
> with proto3, you can do slightly better:
>
> message MSG {
> string account = 1;
> string symbol = 2;
> oneof extra {Extra1 extra1 = 3;Extra2 extra2 = 4;
> }
>
> message Extra1 {
> int32 id = 1;
> }
>
> message Extra2 {
> string foo = 1;
> }
> }
>
> If composition is not what you want, then why not? What real-world problem
> do you have that cannot be effectively solved with one of the above
> strategies?
>
>
>
--
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.
Re: [protobuf] Inheriting protobuf messages
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.
>
On Friday, October 21, 2016 at 1:42:36 AM UTC+5:30, Marcelo Cantos wrote:
>
> It probably wouldn’t be difficult to implement, but it’s not, afaik, a
> design goal for protocol buffers because it is almost never (if ever)
> necessary.
>
> There are two composition approaches available, depending on what your
> needs are. Contain the common stuff:
>
> message Common {
> required string account = 1;
> required string symbol = 2;
> }
> message MSG1 {
> required common = 1
> }
> message MSG2 {
> required common = 1
> required int32 id = 2;
> }
>
> Or contain the variable stuff:
>
> message MSG {
> required string account = 1;
> required string symbol = 2;
> optional Extra1 extra1 = 3;
> optional Extra2 extra2 = 4;
>
> message Extra1 {
> required int32 id = 1;
> }
>
> message Extra2 {
> required string foo = 1;
> }
> }
>
> with proto3, you can do slightly better:
>
> message MSG {
> string account = 1;
> string symbol = 2;
> oneof extra {Extra1 extra1 = 3;Extra2 extra2 = 4;
> }
>
> message Extra1 {
> int32 id = 1;
> }
>
> message Extra2 {
> string foo = 1;
> }
> }
>
> If composition is not what you want, then why not? What real-world problem
> do you have that cannot be effectively solved with one of the above
> strategies?
>
> On Thursday, 20 October 2016 17:50:22 UTC+11, Saurabh Kumar wrote:
>
> Understood but this is not what I wanted in the first place.
>>
>> Does someone has any idea about what makes it difficult to implement
>> this? Also, is there a clever way to have the same behaviour?
>> Basically, here I want to avoid copy pasting same fields over and over
>> again (makes code less maintainable).
>>
>> Any ideas are welcome.
>>
>> On Thursday, October 20, 2016 at 1:33:04 AM UTC+5:30, Feng Xiao wrote:
>>>
>>> I meant something like:
>>>
>>> message Header {
>>> string account = 1;
>>> string symbol = 1;
>>> }
>>>
>>> message Msg1 {
>>> Header header = 1;
>>> ...
>>> }
>>>
>>> message Msg2 {
>>> Header header = 1;
>>> ...
>>> }
>>>
>>> On Wed, Oct 19, 2016 at 12:42 PM, Saurabh Kumar
>>> wrote:
>>>
Thanks for the reply. What exactly do you mean by common header?
On Thu, 20 Oct 2016 at 1:06 AM, Feng Xiao wrote:
>
>
> On Wed, Oct 19, 2016 at 4:03 AM, Saurabh Kumar
> wrote:
>
>> Hi,
>>
>> This question is regarding inheritance in protobuf C++ library. I
>> will explain what I am looking for with a concrete example.
>>
>> I have this message definition:
>>
>> message MSG1
>> {
>>required string account = 0;
>>required string symbol = 1;
>> }
>>
>> Now I want to extend this message and define a new message like this:
>> message MSG2
>> {
>>required string account = 0;
>>required string symbol = 1;
>>required int32 id = 2;
>> }
>>
>> You will notice that first two fields of MSG2 are exactly same as
>> MSG1 (they are intended to be like that). But here I had to copy paste
>> the
>> common fields again.
>> Can I do something like this?
>>
>> message MSG2 extends MSG1
>> {
>>required int32 id = 2;
>> }
>>
>> I have already thought about using it like:
>> message MSG2
>> {
>>required MSG1 msg1 = 0;
>>required int32 id = 2;
>> }
>> But this is not really what I want.
>>
>> What's the best way to achieve this?
>>
> Protobuf doesn't support inheritance. Having a common header and using
> composition is the best solution.
>
>
>>
>> Thanks,
>> Saurabh
>>
> --
>> 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+u...@googlegroups.com.
>> To post to this group, send email to prot...@googlegroups.com.
>>
Re: [protobuf] Inheriting protobuf messages
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.
