Sorry about that. I had written 'personal preference' because I thought it
is hard to convey why I have to do it.
I think simplest way to convey would be, there is one proto definition say
commonmsg.proto. I do not own this and can not make any changes to this.
Now I want to define many messages (that I own) and have some additional
optional/required parameters and common ones from commonmsg.proto. So the
suggestion about variable stuff is not applicable anymore:
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; } }
Nesting (containing) is not what I want, because the nature of fields is
such that it does not make much sense. All of them belong to same level.
I guess it might still not make sense to you, but you know what I am
looking for and it could be a hack :)
On Friday, October 21, 2016 at 4:44:39 PM UTC+5:30, Marcelo Cantos wrote:
>
> I know exactly what you're trying to achieve, but you haven't presented a
> strong case for why you want this. Both the approaches I've suggested avoid
> the copy pasting you're worried about, and personal preference isn't an
> argument.
>
> On Fri, 21 Oct 2016 at 21:55 Saurabh Kumar <[email protected]
> <javascript:>> wrote:
>
>> Hi,
>>
>> Thanks for the suggestions below. I agree with you that these approaches
>> address most of the real life scenarios. What I am really looking for is
>> more of a syntactic sugar. In my case, I want to avoid any kind of nesting
>> as a personal preference. I just want to avoid copy pasting same members at
>> multiple places and have the overhead of keeping them updated everywhere.
>>
>> I don't even mind if we had a certain kind of preprocessor to achieve
>> this i.e.
>> #define common_fields required int32 a; \
>> required int32 b; \
>>
>> message msg1 {
>> common_fields;
>> required int32 c;
>> }
>>
>>
>> message msg2 {
>> common_fields;
>> required int32 d;
>> }
>>
>> Does it make sense?
>>
>>
>> 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 <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Thanks for the reply. What exactly do you mean by common header?
>>>>>>
>>>>>> On Thu, 20 Oct 2016 at 1:06 AM, Feng Xiao <[email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 19, 2016 at 4:03 AM, Saurabh Kumar <[email protected]>
>>>>>>> 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 [email protected].
>>>>>>>> To post to this group, send email to [email protected].
>>>>>>>> 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 [email protected].
>>>>>> To post to this group, send email to [email protected].
>>>>>> 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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
