On Fri, Dec 28, 2018 at 1:08 PM Josh Humphries <[email protected]> wrote: > > On Fri, Dec 28, 2018 at 11:57 AM Michael Powell <[email protected]> wrote: >> >> Hello, >> >> At present I've "compiled" the .proto (v2) to its AST; analogous, I >> think, to the protoc "descriptor". I've got parent to child >> relationships captured intrinsic to the AST being synthesized. I've >> developed a visitor that connects the parent to the children, >> subsequent to the parsing to AST, which captures the "having parent" >> aspect. So at this point I am confident I can navigate the AST >> downwards as well as upwards, to siblings, etc. >> >> Now, when deciding how to prefix and otherwise "build" the path to >> element names, I assume it is not unlike Java, starting with the >> package name, extending through the messages, etc. Or C++ and/or C#, >> starting from a namespace. >> >> I have scanned over the C++ and Java and so forth Proto v2 specs, >> language guides, etc, and at first blush, prima facie, it makes sense. >> >> However, how would one handle cases where more than one package exists >> in a single .proto file? Say, I had: >> >> package "foo.baz"; >> message A { /* ... */ } >> package "baz.fiz"; >> message B { /* ... */ } >> >> I gather the A fully qualified name would be ".foo.baz.A", correct? >> Whereas the fully qualified B name would be ".baz.fiz.B"? > > That is not a valid proto file. Proto files can have only one package > declaration. If you try to compile this file with protoc, you'll get an error > pointing to the second package declaration.
Well, I wouldn't think it is, either, however in the v2 spec, per se, there is nothing there explicitly forbidding it. >> Reading a bit deeper into the docs, there is one area however that >> does not make much sense to me: >> >> https://developers.google.com/protocol-buffers/docs/proto#customoptions >> >> In the MyService, I'm not sure how one can make the leap from MethodOptions >> to: >> >> // ... >> extend google.protobuf.MethodOptions { >> optional MyMessage my_method_option = 50006; >> } >> // ... >> // Note: my_method_option has type MyMessage. We can set each field >> // within it using a separate "option" line. >> option (my_method_option).foo = 567; >> option (my_method_option).bar = "Some string"; >> // ... >> >> Yes, my_method_option is of type MyMessage. That's a given. However, >> there does not appear to be anything connecting that to any element >> the Service would be dealing with. > > > Sorry: I do not understand what you are asking. > >> >> >> Even diving into the Google "descriptor.proto", yes, there are >> "messages" defined, sort of meta-metadata describing what a service >> should look like. Apart from that, I think it is possible the proto >> compiler itself that is binding the pieces together? Because from what >> I can tell, there does not appear to be anything that would suggest >> that a "MethodOptions" should appear anywhere accessible to a service >> RPC method. Certainly not without an "(option)...." prefix, I think? > > > I'm having great difficulty following along. When you say a "a MethodOptions > should appear anywhere accessible to a service RPC method", I really don't > follow. Really, I'm just trying to gain some comprehension over how the elements connect. From the v2 examples, which extend out from the Protocol Buffer .protos themselves, it seems, I'm not sure that I can readily identify the names, etc, that would lend itself to the example as it has been illustrated. > Is this question how to use custom options or how to support them when > writing a custom parser and linker for proto sources? The MethodOptions > message represents all options defined in an RPC method declaration. Each > field represents a possible "known" option (no parentheses around name). And > it has an extension range in which custom options are defined (whose names > must be referenced in source surrounded by parentheses). >> >> Seems very ad-hoc to me. Am I missing something there? > > Well, it's general in that all options and custom options can be parsed the > same way (well, slight variance for enum value and field options, just due to > their compact syntax -- but semantics are the same). > > Do you mean "ad hoc" because these options are defined in the language spec? > If so, that is intentional, mainly due to the fact that they can reference > custom options defined in other proto source files. So resolution of option > names must happen during linking. In that they are NOT defined in the language spec, per se. There is nothing in the spec that suggests there should be a "java_package", for instance, or any of the other options. These seem more like "protoc" "run" time options than anything else. They might be interesting for what I'm wanting to do with this, or I could ignore them altogether, for that matter, depending on the message, option, etc. So.. now that I have the AST connected, feel confident I can navigate that meta- or meta-meta-data, descriptors, etc, just trying to gain a further sense of what that linkage might involve for my purposes. >> Not to mention the "ad hoc" appearance of "supported" options: >> >> https://developers.google.com/protocol-buffers/docs/proto#options >> >> Just looking for a little clarification here, if you please. >> >> Cheers, >> >> Michael Powell >> >> -- >> 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 https://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 https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
