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"?
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.
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?
Seems very ad-hoc to me. Am I missing something there?
...
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.
