On Mon Jan 26 2015 at 5:38:22 PM Ryan Gaudon <[email protected]> wrote:
> As a new user it's encouraged to begin implementation with PB3.0+ opposed
> to 2.6. With that being said, since I'm beginning integration now and
> replacing XStream with this, where would you suggest I start? There is very
> little / no documentation available at this time, and there hasn't been an
> update since.
>
Most of the documentation on our developer guide site still applies to
proto3. We don't have any documentation for proto3 specific features though.
>
> Specifically I'm curious how to go about tackling serialization of objects
> that inherit properties and methods from a parent class. IIRC, this was
> handled with extensions and .setExtension() in older version, however I was
> unable to figure out how to use the new 'any' type and the compiler threw
> errors when attempting to work with it blindly.
>
Sorry, but "Any" is not added in this alpha version. In proto3, "Any" will
be a pre-defined message type. Its definition looks like this:
package google.protobuf;
message Any {
string type_url = 1;
bytes value = 2;
}
You could define such a message yourself and use it as a temporary
solution. In the next alpha version we'll provide these types and utility
functions to work with an Any message.
>
> Is there anything you have available to get those started off with
> protobuf 3?
>
>
> On Thursday, December 11, 2014 at 1:21:01 AM UTC-3:30, 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.
