Possibly. Although it may end up being more confusing than useful - and could easily get out of date if we provide some sort of support. (And as mentioned, you could potentially use a bytes field instead, when we have dynamic message support.)
I'll reach out to our tech writers and see what they think... Jon On Monday, 7 December 2015 20:24:56 UTC, James Hugard wrote: > > Would it be worth mentioning on the Google documentation pages that > Self-Describing messages are not supported in Proto3? > > https://developers.google.com/protocol-buffers/docs/techniques > > > jh > > > On Thursday, December 3, 2015 at 4:46:29 AM UTC-8, Jon Skeet wrote: >> >> I agree it's a limitation - but it just comes naturally with the >> territory of only supporting proto3. >> >> Now there's nothing to say that we'll *never* support proto2 - but the >> extra complexity of supporting extensions and different models of field >> presence would have significantly delayed the whole effort. (It would also >> have made the code base harder to maintain - I'm much happier with the new >> code base than the old proto2-only one...) >> >> Jon >> >> On Wednesday, 2 December 2015 16:56:12 UTC, James Hugard wrote: >>> >>> Hi Jon: >>> >>> Pity that there will be no official support. That means I shall be >>> unable to have fully self-describing messages. Further, I believe that >>> will also preclude writing proto compiler plugins in C# (F#, VB, etc.). >>> >>> As an interim solution (or a permanent one?), I have hand-edited >>> Descriptor.proto to remove everything incompatible with proto3, compiled it >>> with proto3 syntax, thus generating C# code. The main issue is support for >>> extension ranges - without those, it is impossible to declare custom >>> options (which we also use). Therefore, I simply compiled all other proto >>> files using the original (proto2) descriptor.proto file then hand edited >>> the generated code to reference >>> Google.ProtocolBuffers.DescriptorProtos.FileDescriptorProto. >>> >>> Less than ideal, and certainly not acceptable for production use. >>> >>> I'm eyeing the Froto <https://github.com/ctaggart/froto> project as a >>> possible long-term solution, but with a need to support many languages >>> that's also less than ideal and would take .NET out of the primary >>> ecosystem. >>> >>> Thanks for the reply! >>> >>> jh >>> >>> >>> On Wednesday, December 2, 2015 at 6:46:52 AM UTC-8, Jon Skeet wrote: >>>> >>>> On Wednesday, 2 December 2015 04:45:30 UTC, James Hugard wrote: >>>>> >>>>> Trying to use a FileDescriptorSet in my own proto3 message definition >>>>> with C# 3.0.0-alpha4 generated code, but running into compilation issues. >>>>> >>>>> The code generates just fine using protoc.exe, but the generated code >>>>> won't compile due to a missing reference to "global >>>>> ::Google.Protobuf.FileDescriptorSet". >>>>> >>>>> Attempting to generate code from the protobuf definition fails, >>>>> because the Descriptor.proto file uses proto2 syntax and hence is not >>>>> supported by the C# code generator. >>>>> >>>>> A C# object for FileDescriptorSet does not appear to be in >>>>> Google.Protobuf assembly. Nor could I figure out how to modify the >>>>> generated code to compile properly. Attempting to manually edit the >>>>> generated code to use >>>>> >>>>> Google.Protobuf.Collections.RepeatedField< >>>>> Google.Protobuf.Reflection.FileDescriptor > failed with a "no >>>>> conversion to IMessage<>", or something similar. >>>>> >>>>> >>>>> Please, what is the right way to use a FileDescriptorSet in my own >>>>> proto? >>>>> >>>> >>>> I'm afraid you can't. We generate the code for descriptor.proto so that >>>> we can use it within the protobuf runtime, but it's all internal - we >>>> don't >>>> have any codegen to support proto2 semantics, and we've carefully looked >>>> at >>>> what we need from descriptor.proto to check that it's okay with what we >>>> need to use it for internally, but that's all. It would be a bad idea to >>>> expose it separately. >>>> >>>> If we ever retroactively fit proto2 support, that would be fine, of >>>> course - but until then, I'm afraid there's no way of doing this. You >>>> could >>>> create your own proto3 copy of descriptor.proto, taking only the bits you >>>> care about, and if you're very careful you *may* then be able to >>>> interoperate with code that actually expects a FileDescriptorSet... but >>>> you >>>> would definitely need to be careful. >>>> >>>> Jon >>>> >>>> >>> -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
