Sorry, but we don't allow subclassing of protocol buffer objects (in any
language). Allowing this leads to too many "fragile base class" problems.
If you want to expose all of the fields of your protocol message (which is
what you'd get from subclassing), you can always add an accessor to your
wrapper which returns the wrapped message object. Then you do not need to
add a new accessor for every new field added. If you only want to expose
some fields but not others, you could separate your message into two
messages like:
message MyMessage {
message Public {
// public fields here
}
required Public public_fields = 1;
// private fields here
}
Then your wrapper class can provide a method to access the MyMessage.Public
part but not the rest.
On Sun, Jan 18, 2009 at 5:03 PM, Chris <[email protected]> wrote:
>
> Thanks Mark, Its java. So far people keep recommending me what I am
> already doing (delegation) which is itself not maintainable. Sounds
> like there is a need for a code generator to generate the delegation
> of those methods you want to expose :-}
>
> On Jan 18, 2:17 am, Marc Gravell <[email protected]> wrote:
> > What language are you using? In C#, "partial classes" are a viable way
> > of adding extra logic into generated classes - the protobuf-net
> > generator allows this fairly well. In the more general sense, consider
> > encapsulation over inheritance, or simply keep the two separate (for
> > example, passing the generated object into static methods defined in
> > the business class etc),
> >
> > Marc Gravell
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---
