On Thu, Apr 30, 2015 at 12:52 PM, Nikolay Mladenov < [email protected]> wrote:
> I understand it was an intentional design decision, I just fail to > understand the reasoning for it. > I see this statement. > > >>"In proto3, this is an intentional design decision: has_...() methods > go away except for message fields. For oneofs, the idiomatic API pattern is > to use get_oneof_case() to check which field in the oneof is set." > > It is obvious for me that regular non-message fields should not have > has_.. in proto3. > > but for oneof has_... makes perfect sense. > It is still defined because it is convenient for the "internal" code. > > But it is also convenient for other uses, so hiding it is superficial. > > I now have to redefine all such method for my needs and they have exactly > the same definitions as the private members, > but are just a hassle to write/update and use.... > The intention is to make the public API simpler and consistent. As there is already a way to check for field presence for oneof fields, we decide to not provide has_ methods. > > > > > > > On Thu, Apr 30, 2015 at 9:30 AM, Alfred Kwan <[email protected]> wrote: > >> Nikolay, the has_foo being private is actually intentional, see this closed >> issue <https://github.com/google/protobuf/issues/234>. >> >> Alfred >> >> >> On Wednesday, April 29, 2015 at 6:36:59 PM UTC-4, Nikolay Mladenov wrote: >>> >>> I am also evaluating proto2 vs proto3 and even though it seems proto3 >>> should be the way to go I really miss the has_** functionality in proto3. >>> >>> It seems the following proto pattern may be a workaround: >>> >>> message M{ >>> oneof optional_value{ >>> int32 value = 1; >>> } >>> } >>> >>> It does generate value(), set_value(), clear_value() and has_value() >>> methods (C++) but unfortunately the has_value is private. >>> Is there a reason such a useful and short method is declared private (it >>> implementation only uses public functionality as well) >>> >>> >>> >>> On Wednesday, February 11, 2015 at 3:55:03 PM UTC-5, Alfred Kwan wrote: >>>> >>>> Thanks for pointing me to "oneof". I gave it a try and I have two >>>> questions: >>>> 1) I see the has_() being generated for all the fields inside oneof. Is >>>> this kind of has_() function here to stay throughout subsequent V3 >>>> releases? >>>> 2) Since oneof does not allow a repeated field in both V2/3, is there >>>> pro/cons in case I create one extra layer of structure i.e.: >>>> message manyMsg{ // workaround: wrap the repeating message >>>> repeated oneMsg = 1; >>>> } >>>> message unionMsg{ >>>> oneof testOneof{ >>>> manyMsg msg = 1; // doesn't allow repeated >>>> uint32 foo = 2; >>>> } >>>> } >>>> >>>> >>>> >>>> On Sunday, February 8, 2015 at 11:01:04 PM UTC-5, Feng Xiao wrote: >>>>> >>>>> The union types are obsoleted by oneof: >>>>> https://developers.google.com/protocol-buffers/docs/proto#oneof >>>>> >>>>> On Sat, Feb 7, 2015 at 4:53 AM, Alfred Kwan <[email protected]> wrote: >>>>> >>>>>> To implement the has_boo() in 3.0 implies one boolean per each truly >>>>>> optional field, which means additional maintenance is now required, e.g. >>>>>> matching naming scheme for the pool together with the optional struct, >>>>>> also >>>>>> should we group all booleans together or should they sit right next to >>>>>> the >>>>>> to corresponding optional structures... >>>>>> >>>>>> With the uncertainty of how "any" replaces "extensions" plus the >>>>>> removal of has_boo(), it seems like new adopters (I'm one of them) should >>>>>> pick V2 over 3.0. >>>>>> >>>>>> On Wednesday, January 28, 2015 at 3:10:39 PM UTC-5, Feng Xiao wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed Jan 28 2015 at 12:06:21 PM Troy Lee <[email protected]> wrote: >>>>>>> >>>>>>>> Feng, >>>>>>>> >>>>>>>> Version 3 removes presence logic. >>>>>>>> How do we exam whether a field is exist or not? >>>>>>>> >>>>>>> This is no possible for singular primitive fields. For singular >>>>>>> message fields, the has methods will still be generated. Basically with >>>>>>> proto3 you'll need to write your code without depending on these dropped >>>>>>> features. It's believed that most users don't use the field presence >>>>>>> logic >>>>>>> much and for those who need this feature adding a bool field is an easy >>>>>>> workaround. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> troylee >>>>>>>> >>>>>>>> Feng Xiao於 2014年12月11日星期四 UTC+8下午12時51分01秒寫道： >>>>>>>> >>>>>>>>> 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. >>>>>> >>>>> >>>>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Protocol Buffers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/protobuf/ZRpcfmeGK6s/unsubscribe. >> To unsubscribe from this group and all its topics, 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. > -- 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.
