424139789a
This change makes it such that Files now functionally registers all descriptors in a file (not just enums, messages, extensions, and services), but also including enum values, messages fields/oneofs, and service methods. The ability to look up any descriptor by full name is needed to: 1) properly detect namespace conflicts on enum values 2) properly implement the relative name lookup logic in reflect/protodesc The approach taken: 1) Assumes that a FileDescriptor has no internal name conflicts. This will (in a future CL) be guaranteed by reflect/protodesc and is guaranteed today by protoc for generated descriptors. 2) Observes that the only declarations that can possibly conflict with another file are top-level declarations (i.e., enums, enum values, messages, extensions, and services). Enum values are annoying since they live in the same scope as the parent enum, rather than being under the enum. For the internal data structure of Files, we only register the top-level declarations. This is the bare minimum needed to detect whether the file being registered has any namespace conflicts with previously registered files. We shift the effort to lookups, where we now need to peel off the end fragments of a full name until we find a match in the internal registry. If a match is found, we may need to descend into that declaration to find a nested declaration by name. For initialization, we modify internal/filedesc to initialize the enum values for all top-level enums. This performance cost is offsetted by the fact that Files.Register now avoids internally registering nested enums, messages, and extensions. For lookup, the cost has shifted from O(1) to O(N), where N is the number of segments in the full name. Top-level descriptors still have O(1) lookup times. Nested descriptors have O(M) lookup times, where M is the level of nesting within a single file. Change-Id: I950163423431f04a503b6201ddcc20a62ccba017 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/183697 Reviewed-by: Damien Neil <dneil@google.com>
Next Generation Go Protocol Buffers
WARNING: This repository is in active development. There are no guarantees about API stability. Breaking changes will occur until a stable release is made and announced.
This repository is for the development of the next major Go implementation of protocol buffers. This library makes breaking API changes relative to the existing Go protobuf library. Of particular note, this API aims to make protobuf reflection a first-class feature of the API and implements the protobuf ecosystem in terms of reflection.
Design Documents
List of relevant design documents:
Contributing
We appreciate community contributions. See CONTRIBUTING.md.
Reporting Issues
Issues regarding the new API can be filed at
github.com/golang/protobuf.
Please use a APIv2: prefix in the title to make it clear that
the issue is regarding the new API work.