[protobuf] Re: Reflecting Custom Options in Protobuf C#
Looks like the custom options API is not exposed yet in 3.0. Is there any plan to add that? On Friday, April 29, 2016 at 9:37:11 AM UTC-7, Jon Skeet wrote: > On Thursday, 28 April 2016 22:58:42 UTC+1, TravG wrote: >> >> I'm using Protobufs in C# and wondering how I can get access to custom >> options I've annotated on a field at runtime via reflection. I see some >> indications that this should be possible: >> > > Hmm... I don't *think* we expose it at the moment. Will look into it. I > don't want to expose the existing options protos for various reasons. Do > you have a preferred API in mind? It's probably easiest to keep track of > this as a Github feature request - are you happy to open one? > > Jon > -- 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 protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
Re: [protobuf] Default Values vs Missing Values
I've created an issue for this: https://github.com/google/protobuf/issues/1606 -- 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 protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
Re: [protobuf] Default Values vs Missing Values
On Wednesday, May 18, 2016 at 11:32:03 AM UTC-7, Feng Xiao wrote:
>
>
>
> On Tue, May 17, 2016 at 7:53 PM, Teddy Zhang > wrote:
>
>> I'm really not happy to see that proto3 removed the ability in generate
>> code for check whether a field exits or not.
>>
>> For a message like this:
>> message Test1 {
>> required int32 a = 1;
>> }
>> If field a is present, the encoded message will have field with id 1 and
>> its value. If the field is not set, the encoded message will not have field
>> id 1.
>> In proto2 generated code, it provides a has method to check whether the
>> field exists or not.
>> In proto3, this is no such thing. During deserialization, if the field is
>> not exists, default value is set. So you can't tell whether the field does
>> not exist or have a default value. That doesn't match the underline
>> encoding anymore.
>>
>> This is a breaking change and will portentially impact a lot of people.
>> Basically we're losing nullable support.
>> For our project, we heavily depends on that. There are workarounds (add
>> a Boolean field) but it is ugly. I think that will stop us from moving from
>> proto2 to proto3 (may need find alternatives).
>>
> There are two workarounds to get back the field presence info in proto3.
> 1. Use a wrapper message, such as google.protobuf.Int32Value
> <https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto#L84>.
>
> In proto3, message fields still have has-bits.
>
Wrapper field consumes more space. Also, the wire format is not compatible
when move from proto2 to proto3 (given the schema needs to change).
> 2. Use an oneof. For example:
> message Test1 {
> oneof a_oneof {
> int32 a = 1;
> }
> }
> then you can check test.getAOneofCase().
>
Same issue as above.
>
>
>
>> Can we add the functionality back?
>>
> It's very unlikely to happen as proto3 features are already finalized and
> implemented in many languages.
>
Is it possible to add a option on message to control this?
I know proto3 is probably in last beta and try to avoid big changes.
However, remove support for this creates a lot of pain in a big system
which already leverage this feature, and may move many people away.
--
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
Re: [protobuf] Default Values vs Missing Values
On Wednesday, May 18, 2016 at 11:32:03 AM UTC-7, Feng Xiao wrote:
>
>
>
> On Tue, May 17, 2016 at 7:53 PM, Teddy Zhang > wrote:
>
>> I'm really not happy to see that proto3 removed the ability in generate
>> code for check whether a field exits or not.
>>
>> For a message like this:
>> message Test1 {
>> required int32 a = 1;
>> }
>> If field a is present, the encoded message will have field with id 1 and
>> its value. If the field is not set, the encoded message will not have field
>> id 1.
>> In proto2 generated code, it provides a has method to check whether the
>> field exists or not.
>> In proto3, this is no such thing. During deserialization, if the field is
>> not exists, default value is set. So you can't tell whether the field does
>> not exist or have a default value. That doesn't match the underline
>> encoding anymore.
>>
>> This is a breaking change and will portentially impact a lot of people.
>> Basically we're losing nullable support.
>> For our project, we heavily depends on that. There are workarounds (add
>> a Boolean field) but it is ugly. I think that will stop us from moving from
>> proto2 to proto3 (may need find alternatives).
>>
> There are two workarounds to get back the field presence info in proto3.
> 1. Use a wrapper message, such as google.protobuf.Int32Value
> <https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto#L84>.
>
> In proto3, message fields still have has-bits.
>
Wrapper field consumes more space. Also, the wire format is not compatible
when move from proto2 to proto3 (given the schema needs to change).
> 2. Use an oneof. For example:
> message Test1 {
> oneof a_oneof {
> int32 a = 1;
> }
> }
> then you can check test.getAOneofCase().
>
Same issue as above.
>
>> Can we add the functionality back?
>>
> It's very unlikely to happen as proto3 features are already finalized and
> implemented in many languages.
>
Is it possible to add a option on message to control this?
I know proto3 is probably in last beta and try to avoid big changes.
However, remove support for this creates a lot of pain in a big
system which already leverage this feature, and may move many people away.
>
>
>>
>>
>> On Saturday, March 26, 2016 at 11:47:08 AM UTC-7, Ilia Mirkin wrote:
>>
>>> Use proto2, which has the has_* checks per field. (Using get_* you
>>> still get the default value, of course.) It's extremely unfortunate
>>> that this functionality was removed in proto3, I see that making
>>> proto3 unattractive for all but the simplest uses of protos. I know in
>>> almost every protobuf use-case I've had, the presence accessors were
>>> imperative to proper operation.
>>>
>>> On Sat, Mar 26, 2016 at 2:43 PM, Yoav H wrote:
>>> > Hi,
>>> >
>>> > I wanted ask regarding the decision to populate fields with default
>>> values,
>>> > even if they do not appear in the encoded message.
>>> > If I want to send a "patch" message, where I want to update just the
>>> > provided fields, how can I do that with protobuf (without adding
>>> IsXXXSet
>>> > for every field)?
>>> >
>>> > Why not add another type, representing a default value?
>>> > So the schematics would be, if the field is missing, it is null, and
>>> if the
>>> > field exists, but with this "missing value" type, it will get the
>>> default
>>> > value?
>>> >
>>> > Thanks,
>>> > Yoav.
>>> >
>>> > --
>>> > 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 protobuf+u...@googlegroups.com.
>>> > To post to this group, send email to prot...@googlegroups.com.
>>> > Visit this group at https://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 protobuf+u...@googlegroups.com .
>> To post to this group, send email to prot...@googlegroups.com
>> .
>> Visit this group at https://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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
Re: [protobuf] Default Values vs Missing Values
I'm really not happy to see that proto3 removed the ability in generate
code for check whether a field exits or not.
For a message like this:
message Test1 {
required int32 a = 1;
}
If field a is present, the encoded message will have field with id 1 and
its value. If the field is not set, the encoded message will not have field
id 1.
In proto2 generated code, it provides a has method to check whether the
field exists or not.
In proto3, this is no such thing. During deserialization, if the field is
not exists, default value is set. So you can't tell whether the field does
not exist or have a default value. That doesn't match the underline
encoding anymore.
This is a breaking change and will portentially impact a lot of people.
Basically we're losing nullable support.
For our project, we heavily depends on that. There are workarounds (add
a Boolean field) but it is ugly. I think that will stop us from moving from
proto2 to proto3 (may need find alternatives).
Can we add the functionality back?
On Saturday, March 26, 2016 at 11:47:08 AM UTC-7, Ilia Mirkin wrote:
> Use proto2, which has the has_* checks per field. (Using get_* you
> still get the default value, of course.) It's extremely unfortunate
> that this functionality was removed in proto3, I see that making
> proto3 unattractive for all but the simplest uses of protos. I know in
> almost every protobuf use-case I've had, the presence accessors were
> imperative to proper operation.
>
> On Sat, Mar 26, 2016 at 2:43 PM, Yoav H > wrote:
> > Hi,
> >
> > I wanted ask regarding the decision to populate fields with default
> values,
> > even if they do not appear in the encoded message.
> > If I want to send a "patch" message, where I want to update just the
> > provided fields, how can I do that with protobuf (without adding
> IsXXXSet
> > for every field)?
> >
> > Why not add another type, representing a default value?
> > So the schematics would be, if the field is missing, it is null, and if
> the
> > field exists, but with this "missing value" type, it will get the
> default
> > value?
> >
> > Thanks,
> > Yoav.
> >
> > --
> > 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 protobuf+u...@googlegroups.com .
> > To post to this group, send email to prot...@googlegroups.com
> .
> > Visit this group at https://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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] NuGet package for Protobuf 3.0 beta 2?
Now we have Protobuf 3.0 beta 2 on https://github.com/google/protobuf/releases. However, http://www.nuget.org/packages/Google.Protobuf/ only has 3.0.0-alpha4. When will this be updated? Thanks. -- 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 protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
[protobuf] Why ProtoBuf 3 put field numbers in generated classes?
I notice that for ProtoBuf 3 generated classes, they have fields
numbers there.
E.g. for C#:
> public const int LatitudeFieldNumber = 1;
>
> private float latitude_;
> public float Latitude {
> get { return latitude_; }
> set {
> latitude_ = value;
> }
> }
>
Found similar behavior in Java and C++.
I think those should belong to Descriptor, no?
--
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: C# Enum Flags
How do I store a HashSet with protobuf?
Regarding the proto2 implementation, if I defined my enum as 1, 2, 4 etc,
and I set the enum to value 3 (combination of 1 & 2), it serialize the
fields correctly. But when deserialize, I get value 0 back (as 3 is not in
enum).
On Tuesday, November 24, 2015 at 5:10:30 AM UTC-8, Jon Skeet wrote:
> I wasn't anticipating doing so, no. Aside from anything else, it would be
> different from all the other platforms - you'd only end up with a useful
> enum in C# if the developer creating the proto did exactly the right
> thing... and that would look odd for other developers.
>
> I would suggest just using a HashSet instead for a set -
> just like there's EnumSet in Java which is a set of values.
>
> (I'm not sure what you mean by "current implementation is forbidden values
> that are combinations" - you can certainly define enums with values of 1,
> 2, 3, 4, 5 etc in proto2).
>
> Jon
>
>
> On Tuesday, 24 November 2015 00:52:53 UTC, Teddy Zhang wrote:
>>
>> C# supports Enum Flags, which is a nice feature.
>>
>>[Flags]
>>>enum MyColor
>>>{
>>> None = 0,
>>> Black = 1,
>>> Red = 2,
>>> Green = 4,
>>> Blue = 8
>>>};
>>
>>
>> However, protobuf seems doesn't support it. There is no way to define a
>> Flags for an enum.
>> Also, for protobuf2, it seem current implementation is forbidden values
>> that are combinations (e.g. 3). In that case it will treat it like unknown
>> fields.
>> In current protobuf 3 c# implemention, the restriction seems gets
>> removed. However, there is still no way to define the enum as Flags.
>>
>> In Java we also have EnumSet to give similar functionality.
>>
>> Will Protobuf C# implementation support this in the future?
>>
>>
--
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] C# Enum Flags
C# supports Enum Flags, which is a nice feature.
[Flags]
>enum MyColor
>{
> None = 0,
> Black = 1,
> Red = 2,
> Green = 4,
> Blue = 8
>};
However, protobuf seems doesn't support it. There is no way to define a
Flags for an enum.
Also, for protobuf2, it seem current implementation is forbidden values
that are combinations (e.g. 3). In that case it will treat it like unknown
fields.
In current protobuf 3 c# implemention, the restriction seems gets removed.
However, there is still no way to define the enum as Flags.
In Java we also have EnumSet to give similar functionality.
Will Protobuf C# implementation support this in the future?
--
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: Enum values are siblings of their type, not children of it.
Sorry to dig this old thread.
I now one of the solution right now is to put the enum to different proto
file and put them into different package. But that doesn't really work if
the enums are under the same message.
I would suggest add an option for c/c++, like below:
enum Foo {
option c_enum_prefix = "eFoo";
FIRST = 0;
SECOND = 1;
BOTH = 2;
}
And it will generate enum like below in c/c++:
enum Foo {
eFooFIRST = 0,
eFooSECOND = 1,
eFooBOTH = 2
};
This won't affect enum generation in managed language like java/c#, and it
won't break backward compatibility (if the option is not specified,
fallback to old behavior).
Any comments?
On Friday, August 20, 2010 at 11:12:30 AM UTC-7, alopecoid wrote:
> Hi,
>
> This post is about the fact that protobuf enum values use C++ scoping
> rules, meaning that, unlike in Java, enum values are siblings of their
> type, not children of it.
>
> Say I have the following contrived message:
>
> message MyMessage {
> enum Foo {
> FIRST = 0;
> SECOND = 1;
> BOTH = 2;
> }
> required Foo foo = 1;
>
> enum Bar {
> FIRST = 0;
> SECOND = 1;
> BOTH = 2;
> }
> required Bar bar = 2;
> }
>
> This wouldn't compile because the protobuf compiler recognizes the
> fact that for C++, the generated enum values for Foo and Bar would
> conflict with each other.
>
> However, for Java, this wouldn't be a problem. I would like to propose
> that instead of "punishing" the generated Java code because of C++'s
> strange enum behavior (by forcing developers to rename their enum
> values even though they don't collide), that instead, the generated C+
> + enum declarations are wrapped in their own nested namespaces? For
> example, something like:
>
> namespace Foo {
> enum Enum {
> FIRST = 0;
> SECOND = 1;
> BOTH = 2;
> }
> }
>
> namespace Bar {
> enum Enum {
> FIRST = 0;
> SECOND = 1;
> BOTH = 2;
> }
> }
>
> At this point, the enum values would be accessed like Foo::FIRST,
> Bar::FIRST, etc, which would eliminate the enum value collision
> problem altogether, and at the same time make them appear to behave
> more like Java's enum scoping rules (which arguably make more sense).
>
> Thoughts?
>
> Thank you.
--
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: Override ToString behavior in ProtoBuf 3 C# implementation
+Jon who seems to be the developer on this.
On Monday, November 2, 2015 at 6:18:27 PM UTC-8, Teddy Zhang wrote:
>
> I need to override the ToString behavior in C# to make it human readable.
>
> E.g. I defined a message type to represent DateTime in C#, and then write
> a partial class to make it be able to convert from/to DateTime.
>
>> message ProtoDateTime
>>
>> {
>>
>> sfixed64 BinaryData = 1;
>>
>> }
>>
>
> However, the default ToString() doesn't generate human readable contents.
>
> Currently the default implantation is (codegen code):
>
> public override string ToString() {
>
> return pb::JsonFormatter.Default.Format(this);
>
> }
> Which will generate something like this, which is not readable.
> { "dateTime": { "binaryData": "5247507155853679530" } }
>
> Is there a way to override this behavior?
> If not, is there a plan to support this? Thanks.
>
>
--
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] Override ToString behavior in ProtoBuf 3 C# implementation
I need to override the ToString behavior in C# to make it human readable.
E.g. I defined a message type to represent DateTime in C#, and then write a
partial class to make it be able to convert from/to DateTime.
> message ProtoDateTime
>
> {
>
> sfixed64 BinaryData = 1;
>
> }
>
However, the default ToString() doesn't generate human readable contents.
Currently the default implantation is (codegen code):
public override string ToString() {
return pb::JsonFormatter.Default.Format(this);
}
Which will generate something like this, which is not readable.
{ "dateTime": { "binaryData": "5247507155853679530" } }
Is there a way to override this behavior?
If not, is there a plan to support this? Thanks.
--
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1
Will the C# implementation support proto2 messages?
What is the capability story? I assume the wire format is compatible if no
proto3 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
>>> . 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 synta
[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1
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
>>> . 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 fi
