On Thu, Oct 7, 2010 at 5:29 AM, users .... <moofis...@gmail.com> wrote:
> Thank you Kenton and Jason for the advice. I have a couple more
> questions as I move forward with PB implementations.
>
> In the documentation it states that PBs don't make good first class
> citizens in an OO domain model and the suggestion is of course to wrap
> the PB. Through some other posts it is quite evident that you do not
> want people subclassing or using 'extends' in Java on PBs. However,
> in process of looking at wrapping classes it is quite clear the
> Message and Builder interfaces will be common across every PB I
> create, but for each PB there will be a uniqe set of setters, getters,
> and has functions for my protocol member fields. Am I going to get
> into trouble creating the following type of abstract class using
> generics:
>
>
> public abstract class MyAbstractMessage<T extends GeneratedMessage, B
> extends GeneratedMessage.Builder<?>> {
>
>
> protected T message;
> protected B builder;
>
>
> // This is implemented here only to work around an apparent bug in
> the
> // Java compiler and/or build system. See bug #1898463. The mere
> presence
> // of this dummy clone() implementation makes it go away.
> @Override
> public B clone() {
> throw new UnsupportedOperationException(
> "This is supposed to be overridden by subclasses.");
> }
> /**
> * see {...@link GeneratedMessage#newBuilderForType()}...@link
> MessageLite#newBuilderForType()}
> * @param obj
> * @return
> */
> @SuppressWarnings("unchecked")
> public final B newBuilder() {
> return (B) message.newBuilderForType();
> }
>
> /**
> * see {...@link GeneratedMessage.Builder#build()} {...@link
> MessageLite.Builder#build()}
> * @return
> */
> @SuppressWarnings("unchecked")
> public final T build() {
> message = (T) builder.build();
> builder = null;
> return message;
> }
>
> // ... wrap all the Message and Builder interface methods ...
>
> }
>
> Then for each PB I create I would wrap them in an implementation of
> this abstract class and add my additional setters and getters, hide
> what I want about builder creation or message object creation and
> implement interfaces as necessary.
>
> Is this approach heading down a path that will create chaos in my life
> going forward as migrate numerous protocols to the PB implementation?
If you have incredibly complex protos this could be cumbersome to maintain.
But if the API you want to expose users is more than just the setters and
getters that are provided by the generated code, it's the way to go.
> One final question, I have realized enumeration changes may be
> particular difficult to adapt to with compatibility issues. Can you
> point to any strategies here?
>
The advice to avoid required is especially true for enums: if you send a
value that's unknown to the recipient, and the field is required, the client
will fail to parse the entire message (unless it is using the Partial
variants). Otherwise, it's ok that it gets "dropped" (it's just stored in
the unknown fields) since presumably the client has no idea how to handle
that enumeration value anyway.
>
> Thank you for all the input and advice!
>
> On Sep 21, 3:38 pm, Kenton Varda <ken...@google.com> wrote:
> > On Wed, Sep 15, 2010 at 6:03 AM, users .... <moofis...@gmail.com> wrote:
> > > I am implementing PB to provide an external interface and API to a
> > > developing system. I know the interface will change and the extension/
> > > backwards compatibility is a major benefit. When designing the .proto
> > > files should I, for pure flexibility, make everything optional or
> > > repeated fields? If I do this I can then write separate Validate
> > > functions for each implementation revision. I can see an opportunity
> > > to automate the validate function creation with the code generating
> > > capabilities. This will remove the burden of "required is forever"
> > > but will it impact performance or have other negative effects that I
> > > can not see? Is this a good practice for flexible implementations or
> > > are there better patterns?
> >
> > This is exactly what I usually recommend to people, and do in my own
> code.
> > There are no significant performance effects (if anything, performance
> will
> > be better because there are fewer checks to perform when parsing). But
> as
> > Jason says, opinions vary.
> >
> >
> >
> >
> >
> > > Thanks
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Protocol Buffers" group.
> > > To post to this group, send email to proto...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
> <protobuf%2bunsubscr...@googlegroups.com>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/protobuf?hl=en.- Hide quoted text -
> >
> > - Show quoted text -
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
