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 <saurab...@gmail.com> 
>>> wrote:
>>>
>>>> Thanks for the reply. What exactly do you mean by common header?
>>>>
>>>> On Thu, 20 Oct 2016 at 1:06 AM, Feng Xiao <xiao...@google.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 19, 2016 at 4:03 AM, Saurabh Kumar <saurab...@gmail.com> 
>>>>> 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.
>>>>>> Visit this group at https://groups.google.com/group/protobuf.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>> -- 
>>>> 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.
>>>> Visit this group at https://groups.google.com/group/protobuf.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> ​
>

-- 
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.

Reply via email to