John,
Could you please throw some light on how the problem is solved in Avro?
Thanks,
On Thu, Nov 15, 2018, 3:15 PM John Lonergan The flexibility and expressiveness you are after can be found in Avro.
> Having been involved in a pair of big APIs recently, one using proto and
> the other Avro,
The flexibility and expressiveness you are after can be found in Avro.
Having been involved in a pair of big APIs recently, one using proto and the
other Avro, the groups found it significant easier and more sustainable when
using avro.
A key advantage of avro was abstractions.
--
You received
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
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
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
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
Why do they "belong" on the same level? Does containment prevent you from
building the system you want (and how?), or are we'll still really talking
about personal preference?
On Fri., 21 Oct. 2016 at 22:31, Saurabh Kumar
wrote:
> Sorry about that. I had written
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
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
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
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
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++
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
Hi,
This question is regarding inheritance in C++ protobuf library. I will
explain by giving a concrete example.
message MSG1
{
required string account = 0;
required string symbol = 1;
}
message MSG2
{
required string account = 0;
required string symbol = 1;
}
--
You
14 matches
Mail list logo