The Java <https://github.com/google/protobuf/blob/7f3e23707122f31ebfa58b7280bd56cbe77cb44e/java/core/src/main/java/com/google/protobuf/Descriptors.java> and C++ <https://github.com/google/protobuf/blob/7f3e23707122f31ebfa58b7280bd56cbe77cb44e/src/google/protobuf/descriptor.h> protobuf implementations both provide "rich" descriptors: library types that wrap the generated DescriptorProto messages to make them much easier to work with and, generally, more useful.
I've implemented something similar for Go <https://github.com/jhump/protoreflect/blob/4df185295ba66e94f4fd8e8f60f6a34be0cf875b/desc/descriptor.go>. My intended use is to be use them alongside the GRPC reflection <https://github.com/jhump/protoreflect/blob/4df185295ba66e94f4fd8e8f60f6a34be0cf875b/grpcreflect/clientreflection.go> API (which, from a Go client, isn't hugely useful without a better/more usable form of the descriptors). Is this something that would be welcome in the Go protobuf implementation? I am happy to open a pull request and contribute it. But I wasn't sure if the maintainers would prefer it remain a third-party library instead of integrating it into the core library. ---- *Josh Humphries* jh...@bluegosling.com -- 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.
