-
Notifications
You must be signed in to change notification settings - Fork 22
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
feat: support google.golang.org/protobuf #119
Conversation
@@ -128,6 +131,19 @@ type JSONPBUnmarshaler interface { | |||
|
|||
// Marshal marshals a protocol buffer into JSON. | |||
func (m *Marshaler) Marshal(out io.Writer, pb proto.Message) error { | |||
if msgV2, ok := pb.(protov2.Message); ok { |
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.
what is the thinking behind placing this v2 code path (and early return) before the nil and required field checks below which the v1 code path follows?
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.
That stuff except for maybe the nil check would be invalid for v2. Also this is for jsonpb so not performance critical - it's only used on the cli I believe.
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.
can we get a changelog?
Added |
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.
lgtm! We should alias MsgTypeUrl from core and codec in the SDK to this (+ /) 🙏
This adds support for:
google.golang.org/protobuf/proto.Message
typesMessageName
This should remove any incompatibilties or need for type switching the SDK has when using these types.
Given that gogo proto already does a bunch of type switches to see what kind of message is used, this support seems reasonable and goes a long way to providing v2 support for anyone who wants it (we will use this at Regen at least and others will have a choice). Basically, this makes v2 types more with the v1 APIs the SDK uses without needing to change anything on the SDK side.