On Tue, Jan 13, 2015 at 3:05 PM, Arjun Satish <[email protected]> wrote:
> Feng, > > What do you mean when you say "In C++/Java/Python where we support both > proto2 and proto3, default values will continue to exist"? > What I meant is that you can still find its traces in the implementation but the feature itself is not exposed publicly in proto3 (i.e., we are still using it under-the-hood). > When I run protoc (v3) with the syntax="proto3" tag, it shows an error > "Explicit default values are not allowed in proto3." and exits (no code is > generated). This does not let me use other proto 3 features if my proto > definition file contain default values. > > Thanks for your timely responses! Highly appreciate it! > > > > > On Tue, Jan 13, 2015 at 10:35 AM, Feng Xiao <[email protected]> wrote: > >> >> >> On Mon, Jan 12, 2015 at 10:40 PM, Arjun Satish <[email protected]> >> wrote: >> >>> Would it be possible to re-introduce this feature in a subsequent >>> release? It seems like you are still using it under-the-hood. >>> >> In C++/Java/Python where we support both proto2 and proto3, default >> values will continue to exist. In new languages (e.g., ruby) though, the >> support for non-zero default values will be dropped completely. >> >> >>> And because of the benefits I mentioned above, I strongly feel that it >>> will only help the community. >>> >> As far as I know, the decision is final. Internally a lot Google projects >> have already adopted the new syntax and so far we have not heard problems >> caused by disallowing default values. It's unlikely this will be changed in >> the future. The omission of this feature (and other features) is to make >> the language simpler and to allow more idiomatic implementations in a wider >> range of languages. It's believed this decision will help the protobuf >> community (both protobuf maintainers and protobuf users) and we expect >> proto3 to be a version that can be more easily adopted than proto2 by new >> users due to these simplifications. For existing users who rely on removed >> features, they can continue to use proto2 and that will be supported for a >> long time (if not forever). Currently we generally do not recommend >> migrating existing proto2 projects to proto3 because of incompatibility >> issues (e.g., extensions are dropped in proto3) and only recommend new >> users to use proto3. >> >> >>> >>> 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.
