Yes, just to expand on this - the descriptor protos aren't directly 
accessible, but the information contained within them is - via the public 
types in the Google.Protobuf.Reflection namespace.

We're able to do this because we've looked (very carefully!) at how 
descriptor.proto works in terms of proto3 - basically we generate code *as 
if* it were proto3 syntax, and have workarounds for couple of issues that 
throws up.

Jon

On Friday, 9 October 2015 19:18:42 UTC+1, Feng Xiao wrote:
>
> On Fri, Oct 9, 2015 at 10:51 AM, Walter Schulze <[email protected] 
> <javascript:>> wrote:
>
>> In other words C# and those new languages won't be able to serialize the 
>> descriptor?
>>
> descriptor.proto is an exception. It's allowed to be imported by proto3 
> files to support custom options. I.e., the following is explicitly allowed:
> syntax = "proto3";
> package test;
>
> *import "google/protobuf/descriptor.proto";*
>
> *extend google.protobuf.FieldOptions {*
> *  string my_field_option = 123456789;*
> *}*
>
> message TestMessage {
>   int32 value = 1 [*(my_field_option) = "Some extra option data"*];
> }
>
> However, the ability to use these descriptor info at run-time may be 
> limited (or not present) in certain languages. It depends on what API is 
> provided by the specific language. +Jon Skeet could probably say more about 
> how to use/access descriptors in C#.
>
>
>  
>
>>
>> On 9 October 2015 at 19:44, 'Feng Xiao' via Protocol Buffers <
>> [email protected] <javascript:>> wrote:
>>
>>> The decision is not to support proto2 in C# (and probably also for all 
>>> other languages that are new in v3.0.0+).
>>>
>>> On Fri, Oct 9, 2015 at 10:42 AM, Teddy Zhang <[email protected] 
>>> <javascript:>> wrote:
>>>
>>>> Will the C# implementation support proto2 message as well?
>>>> What is the compatibility story between proto2 and proto 3? I assume 
>>>> the wire format is compatible as long as no proto 3 exclusive features 
>>>> are used.
>>>>
>>>>
>>>> On Tuesday, August 4, 2015 at 5:43:36 AM UTC-7, Jon Skeet wrote:
>>>>
>>>>> That looks like you're expecting a protobuf.net-style approach - to 
>>>>> which the answer is "no" and will continue to be "no".
>>>>>
>>>>> The C# support will continue to be based on generated code, but 
>>>>> there's a new code generator and runtime now in the master branch. The 
>>>>> main 
>>>>> changes from the previous code are:
>>>>>
>>>>> - proto3-only support (no proto2 at all)
>>>>> - mutable generated types rather than the Java-style builders and 
>>>>> immutable messages
>>>>>
>>>>> Jon
>>>>>
>>>>> On Monday, 3 August 2015 22:50:06 UTC+1, The Nguyen Xuan wrote:
>>>>>>
>>>>>> Does this version support object type in C# ?
>>>>>>
>>>>>> ex:
>>>>>>
>>>>>> [ProtoMember(1)]
>>>>>> public object A {get;set;}
>>>>>>
>>>>>> thank.
>>>>>>
>>>>>> Vào 11:51:01 UTC+7 Thứ Năm, ngày 11 tháng 12 năm 2014, Feng Xiao đã 
>>>>>> viết:
>>>>>>>
>>>>>>> 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 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] <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.

Reply via email to