Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2016-10-13 Thread Manivannan s
For Enums it is not possible - It's possible to import proto2 message types and use them in your proto3 messages, and vice versa. However, proto2 enums cannot be used in proto3 syntax.

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-10-21 Thread 'Feng Xiao' via Protocol Buffers
On Wed, Oct 21, 2015 at 1:39 PM, wrote: > Is there a plan to also arena allocate string fields? > In the future we will introduce different ctypes for string fields and if you specify ctype=STRING_PIECE on a string field it will be stored as a StringPiece and can then

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-10-10 Thread Jon Skeet
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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-10-09 Thread Walter Schulze
In other words C# and those new languages won't be able to serialize the descriptor? On 9 October 2015 at 19:44, 'Feng Xiao' via Protocol Buffers < protobuf@googlegroups.com> wrote: > The decision is not to support proto2 in C# (and probably also for all > other languages that are new in

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-10-09 Thread 'Feng Xiao' via Protocol Buffers
On Fri, Oct 9, 2015 at 10:51 AM, Walter Schulze 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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-06-15 Thread 'Feng Xiao' via Protocol Buffers
On Fri, Jun 12, 2015 at 12:40 PM, Darin Gordon dar...@gmail.com wrote: Hi Feng What would you say is a reasonable ETA for the protobuf 3 full release? Are you going through a series of RC's first? We will have a series of alpha releases followed by a series of betas. The 3 full release may

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-05-12 Thread 'Feng Xiao' via Protocol Buffers
On Tue, May 12, 2015 at 5:58 PM, Mikhail Nikonov michael.n.niko...@gmail.com wrote: First of all, thanks for the great work; I've been using protobufs for a while, and it's good to see them evolving. One question - if map field is internally emulated by repeated field type, is it packed

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-04-30 Thread Alfred Kwan
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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-04-30 Thread Nikolay Mladenov
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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-04-30 Thread 'Feng Xiao' via Protocol Buffers
On Thu, Apr 30, 2015 at 12:52 PM, Nikolay Mladenov nikolay.mlade...@gmail.com 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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-04-29 Thread Nikolay Mladenov
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(),

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-04-29 Thread 'Feng Xiao' via Protocol Buffers
On Wed, Apr 29, 2015 at 6:21 AM, Nikolay Mladenov nikolay.mlade...@gmail.com 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:

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-03-30 Thread 'Feng Xiao' via Protocol Buffers
On Mon, Mar 30, 2015 at 11:44 AM, Kostiantyn Shchepanovskyi schepanov...@gmail.com wrote: Hi, 3. Removal of extensions, which are instead replaced by a new standard type called Any. Extensions are used for custom options definition in proto2. import google/protobuf/descriptor.proto;

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-03-10 Thread 'Feng Xiao' via Protocol Buffers
On Thu, Feb 26, 2015 at 11:55 PM, Kevin Baker kba...@gmail.com wrote: Hi, Thanks for all your work with protobuf. I am excited about the changes with proto3 that will reduce errors (no forgetting to set has_* in nanopb, yay!) and will make mapping into new languages much simpler, helping our

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-03-10 Thread Kevin Baker
That's great news, thanks!!! Looking forward to proto3! Kevin On Tue, Mar 10, 2015 at 3:24 PM, Feng Xiao xiaof...@google.com wrote: On Thu, Feb 26, 2015 at 11:55 PM, Kevin Baker kba...@gmail.com wrote: Hi, Thanks for all your work with protobuf. I am excited about the changes with

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-03-09 Thread Kevin Baker
Hi, Thanks for all your work with protobuf. I am excited about the changes with proto3 that will reduce errors (no forgetting to set has_* in nanopb, yay!) and will make mapping into new languages much simpler, helping our interop case a lot. My question is: We are currently using protobuf

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-02-11 Thread Alfred Kwan
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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-02-08 Thread 'Feng Xiao' via Protocol Buffers
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 alfred...@gmail.com wrote: To implement the has_boo() in 3.0 implies one boolean per each truly optional field, which means additional maintenance

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-02-08 Thread 'Feng Xiao' via Protocol Buffers
On Sat, Feb 7, 2015 at 4:31 AM, Jeremy Swigart jswig...@gmail.com wrote: I don't understand. If a message is a simple struct then the generated wrapper code would populate it with the default as defined by the proto it was compiled with wouldn't it? Are you suggesting that the implementation

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-02-08 Thread Alfred Kwan
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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-02-08 Thread Alfred Kwan
It seems to be an annoyance now to implement the recommended union types https://developers.google.com/protocol-buffers/docs/techniques#union with the 3.0 because has_foo() is not longer supported. Instead of one bool for each possible message within the union, what do you think about adding a

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-02-06 Thread Jeremy Swigart
I don't understand. If a message is a simple struct then the generated wrapper code would populate it with the default as defined by the proto it was compiled with wouldn't it? Are you suggesting that the implementation on different platforms would lack the wrapper objects generated by

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-28 Thread Walter Schulze
I have declared quite a few file, message, field, etc. extensions on the descriptor. https://github.com/gogo/protobuf/blob/master/gogoproto/gogo.proto These extensions are used to modify the code that is generated. This results in a user being able to create a proto file like this

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-28 Thread 'Feng Xiao' via Protocol Buffers
On Wed Jan 28 2015 at 12:06:21 PM Troy Lee leet...@gmail.com 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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-27 Thread 'Feng Xiao' via Protocol Buffers
On Tue Jan 27 2015 at 5:42:34 AM Walter Schulze awalterschu...@gmail.com wrote: Will the extensions in the descriptor.proto also be changed to Any types? No. That will continue to be supported. descriptor.proto is the only proto that will allow extensions in proto3. On Thursday, 11 December

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-26 Thread 'Feng Xiao' via Protocol Buffers
On Mon Jan 26 2015 at 5:38:22 PM Ryan Gaudon r...@gaudon.ca 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

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-22 Thread gtw . gtw4c
As a new user, we still have need (C++ target) for default values, as well as required fields (e.g., message headers for embedded target). 1) It appears that you are completely removing the default/required capability from the proto3 language. Is this correct ? 2) Will the proto2 language be

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-22 Thread 'Feng Xiao' via Protocol Buffers
On Thu Jan 22 2015 at 4:53:53 PM gtw.gt...@gmail.com wrote: As a new user, we still have need (C++ target) for default values, as well as required fields (e.g., message headers for embedded target). 1) It appears that you are completely removing the default/required capability from the

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-21 Thread 'Feng Xiao' via Protocol Buffers
The proto3 design discussion has lasted for more than half a year and all of them happened as an internal process. We have a lot of design docs, email exchanges and weekly design meetings, but they are not available for public consumption. Currently we are preparing public documentations for

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-21 Thread Sumit Kumar
Which forum was this discussed (dropping of default) ? May be reading it would give some insights into the details. Regards, Sumit Kumar On 13 Jan 2015, at 2:40 pm, Arjun Satish arjun.sat...@gmail.com wrote: Would it be possible to re-introduce this feature in a subsequent release? It

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-21 Thread Sumit Kumar
Specially makes difficult for adoption in financial applications, the has_field was one of the key reasons to migrate over to protofuf. Financial applications need differentiation in-between 0 value set and not set. Eg: Limit order with 0 price is valid but with no price set is invalid.

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-16 Thread 'Feng Xiao' via Protocol Buffers
The reason for dropping field presence is more of the same with dropping default values. Basically we want to simplify protobuf and make it easier to implement efficiently in more languages. We are preparing the proto3 documentation and will share more information about the trade-offs we have

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-16 Thread 'Feng Xiao' via Protocol Buffers
On Thu Jan 15 2015 at 1:10:10 PM Arjun Satish arjun.sat...@gmail.com wrote: Feng, Would it not be better to throw errors/exceptions when you try to serialize to JSON (from languages like C++ or Java) or when code is generated for these particular languages, rather than completely remove the

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-16 Thread V.B.
I suppose what I'm really wondering is: a) How does it simplify the language implementations exactly? b) Why was that not the case for *non*-primitives, which still have presence logic? On Friday, January 16, 2015 at 6:39:56 PM UTC-5, Feng Xiao wrote: The reason for dropping field presence is

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-15 Thread Alex Antonov
I fully second that opinion. We rely a lot on being able to set explicit defaults that are not language defaults (Java 0, , false, etc). It puzzles me to even think as to why someone might want to take that feature away!!! On Wednesday, January 14, 2015 at 6:50:37 AM UTC-6, Jeremy Swigart

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-15 Thread 'Feng Xiao' via Protocol Buffers
On Tue Jan 13 2015 at 3:17:26 PM Arjun Satish arjun.sat...@gmail.com wrote: Since this feature is never going to be exposed, what advice do you have for people who are using this feature and want to migrate to v3? Also, what can we do as users to skip encoding certain fields with the new

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-15 Thread 'Feng Xiao' via Protocol Buffers
On Thu Jan 15 2015 at 7:01:33 AM Alex Antonov aant...@gmail.com wrote: I fully second that opinion. We rely a lot on being able to set explicit defaults that are not language defaults (Java 0, , false, etc). It puzzles me to even think as to why someone might want to take that feature

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-15 Thread Arjun Satish
Feng, Would it not be better to throw errors/exceptions when you try to serialize to JSON (from languages like C++ or Java) or when code is generated for these particular languages, rather than completely remove the feature across the board? On Thu, Jan 15, 2015 at 12:16 PM, 'Feng Xiao' via

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-14 Thread Jeremy Swigart
That sounds like a poor design decision, and one easily readded without breaking anything. If a field doesn't have an explicit default, you use 0 or whatever, thereby not breaking anyone not using them, but if an explicit default is provided that is used instead. I am using that feature as

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-13 Thread 'Feng Xiao' via Protocol Buffers
On Mon, Jan 12, 2015 at 10:40 PM, Arjun Satish arjun.sat...@gmail.com wrote: Would it be possible to re-introduce this feature in a subsequent release? It seems like you are still using it under-the-hood. In C++/Java/Python where we support both proto2 and proto3, default values will continue

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-13 Thread Arjun Satish
Feng, What do you mean when you say In C++/Java/Python where we support both proto2 and proto3, default values will continue to exist? When I run protoc (v3) with the syntax=proto3 tag, it shows an error Explicit default values are not allowed in proto3. and exits (no code is generated). This

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-13 Thread 'Feng Xiao' via Protocol Buffers
On Tue, Jan 13, 2015 at 3:05 PM, Arjun Satish arjun.sat...@gmail.com wrote: Feng, What do you mean when you say In C++/Java/Python where we support both proto2 and proto3, default values will continue to exist? What I meant is that you can still find its traces in the implementation but the

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-13 Thread Arjun Satish
Since this feature is never going to be exposed, what advice do you have for people who are using this feature and want to migrate to v3? Also, what can we do as users to skip encoding certain fields with the new library? Thanks, On Tue, Jan 13, 2015 at 3:10 PM, Feng Xiao xiaof...@google.com

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-12 Thread Arjun Satish
Would it be possible to re-introduce this feature in a subsequent release? It seems like you are still using it under-the-hood. And because of the benefits I mentioned above, I strongly feel that it will only help the community. Best, On Wed, Jan 7, 2015 at 8:01 PM, Feng Xiao xiaof...@google.com

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2015-01-07 Thread 'Feng Xiao' via Protocol Buffers
+liujisi, who should have a better idea of why default value is dropped from proto3 and what alternatives users can rely on. Internally the design of proto3 has been discussed among a group of people for quite a long time, but most of them haven't subscribed this forum though... On Wed, Jan 7,

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2014-12-11 Thread 'Feng Xiao' via Protocol Buffers
On Thu, Dec 11, 2014 at 9:14 AM, Vladimir Agafonkin agafon...@gmail.com wrote: Really awesome! One question about maps — how are they encoded in terms of packed size? How does it compare to just using a repeated message with key/value pairs? Map fields are encoded as a repeated message

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

2014-12-11 Thread Vladimir Agafonkin
Oh, bummer. I was hoping for a more compact map packing. Currently I'm using the following to do this: repeated uint32 properties = 1; // key/value index pairs repeated string keys = 2; // unique keys repeated string values = 3; // unique values On Thursday, December 11, 2014 2:24:09 PM UTC-5,