Would it be possible to re-introduce this feature in a subsequent release? It seems like you are still using it under-the-hood. And because of the benefits I mentioned above, I strongly feel that it will only help the community.
Best, On Wed, Jan 7, 2015 at 8:01 PM, Feng Xiao <[email protected]> wrote: > +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.
