-
Notifications
You must be signed in to change notification settings - Fork 250
Protobuf API v2 support #399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…er, and BUILD changes
…roto.Map values. proto.List value support remaining, as is the conformance refactor
…ion to concrete types.
|
This is awesome @TristonianJones, keep up the good work! |
0ca2f87 to
73c2c0f
Compare
73c2c0f to
473f45e
Compare
fd8e924 to
4b8d624
Compare
dff60df to
abdc913
Compare
abdc913 to
0492f89
Compare
|
To echo what @glerchundi said, great work @TristonianJones |
|
Thanks @achew22 and @glerchundi. I'm happy to finally get this done. |
|
@JimLarson I think it's ready for a first pass. I couldn't enable proto3 |
|
Awesome! |
|
PTAL |
JimLarson
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost done. I added replies on naming the right returned type in bool.go and handling Any messages wrapping other wrappers in type.go.
|
PTAL |
Support for the Golang protobuf v2 API
Breaking changes
Value v. ConvertToNative
Calling
Value()on a proto-based object will likely return a*dynamicpb.Messageinstance rather than the strongly typed proto message. UsingConvertToNative(reflect.TypeOf(&<DesiredType>{})will produce the desired result.DescriptorProto v. Descriptor
Top-level interfaces have shifted away from using the
DescriptorProtoandFileDescriptorProtomessages directly in favor of the protobuf v2 APIprotoreflect.Descriptorandprotoreflect.FileDescriptor.Duration and Timestamp
The
duration.goandtimestamp.goobject types are now derived from go-nativetime.Durationandtime.Timerespectively as the dependence on the protobuf counterparts was not actually necessary.Performance
NativeToValueconversion.map.goandlist.goimplementations were completely refactored to reduce repetitiveConvertToNativecall paths. Many bugs were fixed, and there is now a slightly higher allocation overhead for these object types, but the overall code is much simpler to maintain.map[ref.Val]ref.Valand[]ref.Valas these are the values of CEL literals.Bug Fixes
ConvertToNativecall paths ofcommon/typesobjects have been fixed as a result of testing for conformance with the new proto API.map.govalues can be converted to Go-native structs; however, support for configuring a Go native struct from aproto.Messagefield of typemapis not yet implemented.Benchmarks
These were the changes in evaluation speed which had a notable performance difference (>10%):
Closes #385 #398 #400