Inheritance..

[ctapobep]

So pity protobuf doesn't support inheritance, only because of this I
can't use it. Any forecasts, are creators going to add this feature?

[Henner Zeller]

On Thu, Mar 17, 2011 at 02:41, ctapobep <stanislav....@gmail.com> wrote:
> So pity protobuf doesn't support inheritance, only because of this I
> can't use it. Any forecasts, are creators going to add this feature?

There are good reasons not to support inheritance and it would be a
design problem if it was; so it is likely not supported.

Typically if someone has the reflex to use inheritance, they actually
mean to do something else. So what is the exact use case you want to
address ?

-h

[Christopher Smith]

This.

Protobufs are basically pure data structures, with no behaviour, so
inheritance is basically meaningless. Protobuf has other mechanisms
for doing reuse.

--
Chris

[Marc Gravell]

(resend; forgot to copy the group)

I have a somewhat cavalier approach, do I *do* support that in my implementation, but that is because my main audience is retrofitting to existing classes, or code-first; not contract first.

I won't get into a snare about whether that is right or wrong, but enough people wanted it, so I added t. The stream is still valid protobuf. If you want to get *really* upset, check my blog for the **other** impl-specific features I'm adding; reference tracking (full graphs, and string re-use) and object types not known in advance.

I can feel the "tutting" already :)

Marc

On 17 Mar 2011, at 09:41, ctapobep <stanislav....@gmail.com> wrote:

So pity protobuf doesn't support inheritance, only because of this I
can't use it. Any forecasts, are creators going to add this feature?

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

[ctapobep]

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. I don't
like that lib, but I can't move to protobuf simply because it doesn't
support inheritance.
2. I need to have a grid structure, that may contain any type: String,
int, double, etc. To do so I'd like to have a List<BasicType> as a raw
in a grid, where BasicType is an ancestor for IntType, DoubleType,
StringType, etc. I can't imagine implementing this elegantly without
inheritance.
__
regards

On 17 мар, 19:22, Henner Zeller <henner.zel...@googlemail.com> wrote:

[Austin Ziegler]

On Thu, Mar 17, 2011 at 3:42 PM, ctapobep
<stanislav....@gmail.com> 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
> and a lot of classes were written that leverage this feature. I don't
> like that lib, but I can't move to protobuf simply because it doesn't
> support inheritance.

You can still fake out inheritance with composition. Whatever your
library is that you've wrapped around, you can do this.

> 2. I need to have a grid structure, that may contain any type: String,
> int, double, etc. To do so I'd like to have a List<BasicType> as a raw
> in a grid, where BasicType is an ancestor for IntType, DoubleType,
> StringType, etc. I can't imagine implementing this elegantly without
> inheritance.

That's basically a union.
(http://code.google.com/apis/protocolbuffers/docs/techniques.html#union)

-a
--
Austin Ziegler • halos...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

[ctapobep]

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 by
inheritance, why would someone need to write ugly workarounds?
Protobuf is cool, but without inheritance a lot of audience won't
simply use it.
__
regards

On 17 мар, 22:10, Austin Ziegler <halosta...@gmail.com> wrote:
> On Thu, Mar 17, 2011 at 3:42 PM, ctapobep
>

> <stanislav.bashkirt...@gmail.com> 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
> > and a lot of classes were written that leverage this feature. I don't
> > like that lib, but I can't move to protobuf simply because it doesn't
> > support inheritance.
>
> You can still fake out inheritance with composition. Whatever your
> library is that you've wrapped around, you can do this.
>
> > 2. I need to have a grid structure, that may contain any type: String,
> > int, double, etc. To do so I'd like to have a List<BasicType> as a raw
> > in a grid, where BasicType is an ancestor for IntType, DoubleType,
> > StringType, etc. I can't imagine implementing this elegantly without
> > inheritance.
>
> That's basically a union.
> (http://code.google.com/apis/protocolbuffers/docs/techniques.html#union)
>
> -a
> --

> Austin Ziegler * halosta...@gmail.com * aus...@halostatue.cahttp://www.halostatue.ca/*http://twitter.com/halostatue

[Michael Videlgauz]

On Mar 17, 7:22 pm, Henner Zeller <henner.zel...@googlemail.com>
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 in turn
derives from MessageLite.

On Mar 17, 7:28 pm, Christopher Smith <cbsm...@gmail.com> wrote:
> Protobufs are basically pure data structures, with no behaviour, so
> inheritance is basically meaningless. Protobuf has other mechanisms
> for doing reuse.

Both Message and MessageLite include a lot of methods (bot virtual and
non-virtual) and entire Message behaviour is implemented by them. What
if I am building my design on top of this hierarchy and want to have
my first base message derive from google::protobuf::Message (thus
inherit its rich functionality) and then I want to have other messages
derive from my base message (inheriting functionality that I have
implemented in base message methods). I may or may not add additional
(optional) fields in derived messages - it doesn't matter now. But I
do want different derived classes to re-implement (override or
overload) some methods. In my product messages ARE data structures but
they ALSO ARE entities that have some functionality. And (up to my
understanding of OOP design principles) that functionality is better
to be implemented as those messages methods.

On Mar 17, 7:22 pm, Henner Zeller <henner.zel...@googlemail.com>
wrote:

> Typically if someone has the reflex to use inheritance, they actually
> mean to do something else. So what is the exact use case you want to
> address ?

In my case I have an infrastructural class that receives messages from
a cloud and distributes them between different abstract message
processors. This infrastructural class should not be aware of any
concrete message type. It deals with pointers/references to base type.
Currently because of this protobuf limitation I am using
google::protobuf::Message in that infrastructural class. But I need to
perform some preprocessing on each message before it will be
distributed to an end-point processor. I would very much like this
preprocessing to be implemented in a virtual method declared in base
message class and overridden in derived concrete classes. Again, I
don't want infrastructural class to be aware of concrete message types
and to cast google::protobuf::Message pointers to it.
Of course there are a lot of workarounds but we are talking here not
about workarounds, right?
Thanks

[ksamdev]

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 (re-)store data.

It seems, that you are trying to have a very generic use-case: Automatic serialization/deserialization of complex structures with inheritance. The next logical question would be access level, etc. All that would complicate things and is not what ProtoBuf is made for.

[Michael Videlgauz]

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 can't agree with you that Protobuf is "simple storage". If it
is than I would say that implementation is too expensive for such a
simple goal... Both in supplied code (source and binary) and in code
required to be written by a client
But that is my personal opinion of course...