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 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.
