On Tue, Dec 8, 2015 at 4:50 AM, Jon Skeet <[email protected]> wrote: > 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... > I guess we can be more specific and say something like: "as of 2015-12-08, this self-describing message approach is supported in languages A, B, C... and not in D, E, F".
> > 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. > -- 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.
