-
Notifications
You must be signed in to change notification settings - Fork 212
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
lib/proto: add support for instantiating proto map fields #491
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Fixed author email address for CLA. |
f05b3e6
to
63e081c
Compare
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.
Thanks for this contribution!
With this change, it becomes possible to instantiate `map<k,v>` type fields in Protobuf messages from Starlark. Maps can be constructed from any Starlark type that implements starlark.IterableMapping. Protobuf messages can have most types as keys/values, so the type conformity is checked individually for each key/value pair (as the Starlark side of things is dynamically typed). This has been tested against fairly complex proto messages containing maps. Map operations apart from construction are not supported in this CL.
Fixed those, thanks. |
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.
Looks good! Thanks again.
With this change, it becomes possible to instantiate
map<k,v>
type fields in Protobuf messages from Starlark.Maps can be constructed from any Starlark type that implements starlark.IterableMapping.
Protobuf messages can have most types as keys/values, so the type conformity is checked individually for each key/value pair (as the Starlark side of things is dynamically typed).
This has been tested against fairly complex proto messages containing maps.
Map operations apart from construction are not supported in this CL.