Can I ask for more details about why presence logic was removed (e.g.
hasFoo() ) for primitives? This has been a very useful feature for us.
1. Removal of field presence logic for primitive value fields, removal
> of required fields, and removal of default values. This makes
> pro
Hi Group,
I am trying to serialize/deserialize a sub message using Protobuf.
The reasons for this is signing. I want to be able to sign part of my
message. To be able to do that, I need to canonicalize it somehow.
If it matters, I use protbuf 3.0.0-alpha (With the proto2 language) with
Python3.4.
Hi group,
I am trying to serialize/deserialize a sub message using Protobuf.
The reasons for this is signing. I want to be able to sign part of my
message. To be able to do that, I need to canonicalize it somehow.
If it matters, I use protbuf 3.0.0-alpha (With the proto2 language) with
Python3.
The reason for dropping field presence is more of the same with dropping
default values. Basically we want to simplify protobuf and make it easier
to implement efficiently in more languages. We are preparing the proto3
documentation and will share more information about the trade-offs we have
made.
On Thu Jan 15 2015 at 1:10:10 PM Arjun Satish
wrote:
> Feng,
>
> Would it not be better to throw errors/exceptions when you try to
> serialize to JSON (from languages like C++ or Java) or when code is
> generated for these particular languages, rather than completely remove the
> feature across t
I suppose what I'm really wondering is:
a) How does it simplify the language implementations exactly?
b) Why was that not the case for *non*-primitives, which still have
presence logic?
On Friday, January 16, 2015 at 6:39:56 PM UTC-5, Feng Xiao wrote:
>
> The reason for dropping field presence i
Hey guys,
I'm not sure what's going on, but confusing me plenty. I have the following
simple Enum I've been using for some time.
enum Status {
UNKNOWN = 0;
QUEUED = 1;
IN_PROGRESS = 2;
COMPLETE= 3;
WAIT= 4;
INCO
