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]
> <javascript:>> 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] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> 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.
