+liujisi, who should have a better idea of why default value is dropped from proto3 and what alternatives users can rely on.
Internally the design of proto3 has been discussed among a group of people for quite a long time, but most of them haven't subscribed this forum though... On Wed, Jan 7, 2015 at 18:52 Arjun Satish <[email protected]> wrote: > Did anyone get a chance to look at this request? > > > > > On Wednesday, December 17, 2014 3:54:12 PM UTC-8, Arjun Satish wrote: >> >> Hey guys, >> >> Thanks for all the hard work! >> >> I have a question regarding the decision to drop support for default >> values. Fields which are set to their default values are not serialized. I >> noticed that in the new code (3.0.0-alpha-1 for Java), this condition >> still holds true. But the default values used are the standard ones (0 for >> int64/int32 etc) and cannot be specified in the .proto file. In some of my >> code, I had reasons to use non-zero default values (-1 for some integers, >> 1024 for some others, 3.14 for some doubles etc). Using the old protocol >> buffers, this was trivial to implement. This was a great feature as we >> could save atleast 2 bytes for every "untouched" field (which comes in >> handy when we persist the data :-)). >> >> Is there any way we can retain specification of default values in the >> .proto files and using them in the generated encoders/decoders? >> >> Thanks very much! >> >> Looking forward to the 3.0 release! >> >> Best, >> Arjun Satish >> >> >> On Wednesday, December 10, 2014 8:51:01 PM UTC-8, Feng Xiao wrote: >>> >>> Hi all, >>> >>> I just published protobuf v3.0.0-alpha-1 on our github site: >>> https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1 >>> >>> This is the first alpha release of protobuf v3.0.0. In protobuf v3.0.0, >>> we will add a new protobuf language version (aka proto3) and support a >>> wider range of programming languages (to name a few: ruby, php, node.js, >>> objective-c). This alpha version contains C++ and Java implementation with >>> partial proto3 support (see below for details). In future releases we will >>> add support for more programming languages and implement the full proto3 >>> feature set. Besides proto3, this alpha version also includes two other new >>> features: map fields and arena allocation. They are implemented for both >>> proto3 and the old protobuf language version (aka proto2). >>> >>> We are currently working on the documentation of these new features and >>> when it's ready it will be updated to our protobuf developer guide >>> <https://developers.google.com/protocol-buffers/docs/overview>. For the >>> time being if you have any questions regarding proto3 or other new >>> features, please post your question in the discussion group. >>> >>> CHANGS >>> ======= >>> Version 3.0.0-alpha-1 (C++/Java): >>> >>> General >>> * Introduced Protocol Buffers language version 3 (aka proto3). >>> >>> When protobuf was initially opensourced it implemented Protocol >>> Buffers >>> language version 2 (aka proto2), which is why the version number >>> started from v2.0.0. From v3.0.0, a new language version (proto3) is >>> introduced while the old version (proto2) will continue to be >>> supported. >>> >>> The main intent of introducing proto3 is to clean up protobuf before >>> pushing the language as the foundation of Google's new API platform. >>> In proto3, the language is simplified, both for ease of use and to >>> make it available in a wider range of programming languages. At the >>> same time a few features are added to better support common idioms >>> found in APIs. >>> >>> The following are the main new features in language version 3: >>> >>> 1. Removal of field presence logic for primitive value fields, >>> removal >>> of required fields, and removal of default values. This makes >>> proto3 >>> significantly easier to implement with open struct >>> representations, >>> as in languages like Android Java, Objective C, or Go. >>> 2. Removal of unknown fields. >>> 3. Removal of extensions, which are instead replaced by a new >>> standard >>> type called Any. >>> 4. Fix semantics for unknown enum values. >>> 5. Addition of maps. >>> 6. Addition of a small set of standard types for representation of >>> time, >>> dynamic data, etc. >>> 7. A well-defined encoding in JSON as an alternative to binary >>> proto >>> encoding. >>> >>> This release (v3.0.0-alpha-1) includes partial proto3 support for >>> C++ and >>> Java. Items 6 (well-known types) and 7 (JSON format) in the above >>> feature >>> list are not implemented. >>> >>> A new notion "syntax" is introduced to specify whether a .proto file >>> uses proto2 or proto3: >>> >>> // foo.proto >>> syntax = "proto3"; >>> message Bar {...} >>> >>> If omitted, the protocol compiler will generate a warning and >>> "proto2" will >>> be used as the default. This warning will be turned into an error in >>> a >>> future release. >>> >>> We recommend that new Protocol Buffers users use proto3. However, we >>> do not >>> generally recommend that existing users migrate from proto2 from >>> proto3 due >>> to API incompatibility, and we will continue to support proto2 for a >>> long >>> time. >>> >>> * Added support for map fields (implemented in C++/Java for both >>> proto2 and >>> proto3). >>> >>> Map fields can be declared using the following syntax: >>> >>> message Foo { >>> map<string, string> values = 1; >>> } >>> >>> Data of a map field will be stored in memory as an unordered map and >>> it >>> can be accessed through generated accessors. >>> >>> C++ >>> * Added arena allocation support (for both proto2 and proto3). >>> >>> Profiling shows memory allocation and deallocation constitutes a >>> significant >>> fraction of CPU-time spent in protobuf code and arena allocation is a >>> technique introduced to reduce this cost. With arena allocation, new >>> objects will be allocated from a large piece of preallocated memory >>> and >>> deallocation of these objects is almost free. Early adoption shows >>> 20% to >>> 50% improvement in some Google binaries. >>> >>> To enable arena support, add the following option to your .proto >>> file: >>> >>> option cc_enable_arenas = true; >>> >>> Protocol compiler will generate additional code to make the generated >>> message classes work with arenas. This does not change the existing >>> API >>> of protobuf messages and does not affect wire format. Your existing >>> code >>> should continue to work after adding this option. In the future we >>> will >>> make this option enabled by default. >>> >>> To actually take advantage of arena allocation, you need to use the >>> arena >>> APIs when creating messages. A quick example of using the arena API: >>> >>> { >>> google::protobuf::Arena arena; >>> // Allocate a protobuf message in the arena. >>> MyMessage* message = Arena::CreateMessage<MyMessage>(&arena); >>> // All submessages will be allocated in the same arena. >>> if (!message->ParseFromString(data)) { >>> // Deal with malformed input data. >>> } >>> // Must not delete the message here. It will be deleted >>> automatically >>> // when the arena is destroyed. >>> } >>> >>> Currently arena does not work with map fields. Enabling arena in a >>> .proto >>> file containing map fields will result in compile errors in the >>> generated >>> code. This will be addressed in a future release. >>> ======= >>> >>> Thanks, >>> Feng >>> >> -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
