Thank you for your answer ksamdev
Yes you are righ I am working on an infrastructure for several
different components of my company's software
And although it is not that much generic it does seem to me that
protobuf will not do that much job for me as I was expected at the
begining...
Still, I c
Hi,
I guess, ProtoBuf was made for use as a very simple data container from the
very beginning. User (programmer) is supposed to write wrappers around these
containers. AFAIK, there is no access level control, all set/get methods are
public.
Don't forget, that ProtoBuf is only simple way to (r
On Mar 17, 7:22 pm, Henner Zeller
wrote:
> There are good reasons not to support inheritance and it would be a
> design problem if it was; so it is likely not supported.
Despite all those good reasons protobuf itself uses inheritance. All
my messages derive from google::protobuf::Message, which
1. Yes, you can fake it, a) but do you like fakes? b) some logic may
depend on inheritance itself
2. Yes, I've seen a union thing, but.. that's basically a
workaround ;)
I guess everything is possible without inheritance, but it was
invented because it's handy, if something can be solved elegantly
On Thu, Mar 17, 2011 at 3:42 PM, ctapobep
wrote:
> Inheritance has a lot of usages in our day-to-day work, and thus
> including it into a feature list is a must from my perspective. I have
> two use cases in hand right now:
> 1. Historically we were using another lib that supported inheritance
> a
Inheritance has a lot of usages in our day-to-day work, and thus
including it into a feature list is a must from my perspective. I have
two use cases in hand right now:
1. Historically we were using another lib that supported inheritance
and a lot of classes were written that leverage this feature.
You can't use the same field descriptors for the four classes. But, note
that one thing you *can* do is define a "base" type that just contains the
shared fields, and then parse any of the other types as this type in order
to access the common fields. Since the field numbers match, they are
compa
I thought about these options and settled on multiple classes that all
share a few fields. So indeed duplicate every shared field.
On Jan 28, 2:28 pm, TJ Rothwell wrote:
> Is there a best practice for this use case?
>
> Here are some options.
>
> // Duplicate every field (sounds like you're doing
i have dozens of message classes that all have exactly the same first
few fields (the first 4 to be precise). And prototypes for all my
message classes are loaded by introspection. So all the prototypes are
simply of class Message and i need to use FieldDescriptors to get/set
fields on messages. He
