It doesn't matter that much. I only set UNKNOWN = 2 on the assumption that
pop and push were already assigned and you needed to preserve wire
compatibility. If I were starting from scratch I would probably define
UNKNOWN as the first value and set it to 0. Making it the first value
defined makes it the implicit default value - even if its integer value is
non-zero you can still do this. Mostly it depends on how you want your proto
file to look.
Whether to use this approach or extensions is up to you. This approach works
nicely with switch/case. You could do the same with extensions, but it's a
little bit more verbose. Extensions are primarily useful so that you don't
have to have a centralized definition - other users of this proto can define
their own commands as extensions. Plus there's the lack of support in other
implementations that you've mentioned.
On Fri, May 14, 2010 at 4:53 PM, john mani <john.m...@gmail.com> wrote:
> Thanks.
>
> To make this generic and allow for multiple commands to be added in
> future, would a good strategy be
> to define:
> enum Type { POP = 0, PUSH = 1, UNKNOWN = 100 }, and later add TOP,
> TAIL, etc. etc. as items after PUSH (meaning with values 2, 3 ... ).
>
> So, later we have: enum Type { POP = 0, PUSH = 1, TOP = 2, TAIL = 3,
> UNKNOWN = 100 } and so on ...
>
> Or it really does not matter?
>
> Is this the recommended approach for this pattern? Or should I be
> using extends?
>
> -john
>
> On May 14, 3:15 pm, Jason Hsueh <jas...@google.com> wrote:
> > Clients with the old binary will not be able to read messages containing
> the
> > new enum value. This would get treated as an unknown field, meaning that
> the
> > type field would not be sent in an older client. Since your field is also
> > required, it would fail to parse. So, with this example, you would need
> to
> > make sure that all clients are updated before sending messages containing
> > the enum value.
> >
> > The solution would be to use optional fields, and define an UNKNOWN enum
> > value.
> >
> > e.g.:
> >
> > enum Type { POP = 0, PUSH = 1, UNKNOWN = 2 } // set unknown = 2 for
> > backward compatibility, assuming POP and PUSH are already defined and in
> the
> > wild.
> > message Command {
> > optional Type type = 1 [default = UNKNOWN];
> > ...
> >
> > }
> >
> > When you add TOP, you can start sending messages with that value before
> all
> > clients are updated. The message will now parse successfully on old
> clients,
> > who will get UNKNOWN when they access type().
> >
> >
> >
> > On Fri, May 14, 2010 at 3:07 PM, john mani <john.m...@gmail.com> wrote:
> > > Hi
> >
> > > This is my first attempt at defining a command pattern :
> > > message Command {
> > > required Type type = 1;
> > > optional Value value = 2;
> > > optional Push push = 3;
> > > optional Pop pop = 4;
> > > }
> >
> > > enum Type { POP = 0, PUSH = 1 }
> >
> > > I deploy code using this file.
> >
> > > Later, I want to add a new command, but not break deployed clients.
> > > Can I do so safely:
> >
> > > enum Type { POP = 0, PUSH = 1, TOP = 2 }
> > > message Command {
> > > required Type type = 1;
> > > optional Value value = 2;
> > > optional Push push = 3;
> > > optional Pop pop = 4;
> > > optional Top top = 5;
> > > }
> >
> > > If not, what's the suggested way for achieving something like this?
> > > I read up on 'extend' - would that be a better way? My concern is that
> > > the other language ports (The C one, for example) do not yet support
> > > extend.
> >
> > > thanx
> > > -john
> >
> > > --
> > > 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<protobuf%252bunsubscr...@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<protobuf%2bunsubscr...@googlegroups.com>
> .
> > For more options, visit this group athttp://
> 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<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.
