Description
I have a go program that implements a domain specific language which supports protos. My goal is to use protoc to generate serialized FileDescriptorSet, feed them (in runtime!) to my go program, and use the type information there to dynamically construct proto objects when executing the DSL script.
So far it is all easy, FileDescriptorSet contains all required information.
But as a final step, I want to serialize thus constructed protos, and I don't want to reimplement all serialization code. Looking at the current v2 API, it is almost, but not quite, possible.
My expectations after reading the design doc is that I can reuse all serialization logic as long as I can provide my own implementation of protoreflect.Message interface (and all dependent "value" interfaces).
In practice, protoreflect.Message has Type() MessageType field, and the only way to construct instances of MessageType is through internal/prototype (since MessageType inherits from Descriptor which has doNotImplement).
So it appears, there's no way to construct proto message types "on the fly": protoreflect.Message can represent only messages generated by protoc and embedded into the go binary.
This surprised me, since if this is the intended behavior, all this proto reflection stuff is no more than a (huge) layer of sugar on top of type information already available in v1 API (via Go reflections and descriptor sets).
Will there be a way to write "polyglot" go programs that can manipulate arbitrary proto messages given their MessageDescriptors?