On Thu, May 23, 2013 at 8:48 AM, Ruffian Eo <ruffia...@googlemail.com>wrote:

> I am currently updating my years old implementation of protocol buffers
> for my company. Handwritten parser and code generators etc...
> So while reviewing the current state of the art, I was taken by surprise
> when I saw the (for me) new "import public" construct.
>
> Maybe what is written about this construct is not sufficient on the
> documentation page (It only gives a rather esoteric "dummy-header" example
> at the time of writing this topic).
> Semantics beyond that example can only be guessed.
>
> Let's assume there are 3 .proto files:
>
> // File A.proto
> package A;
>
> message Base
> {
>   required string hello = 1;
> }
>
> // File B.proto
> package B;
> import "A.proto";
>
> message UsesABbase
> {
>   required A.Base greeting = 1;  // legal or only legal if above "import
> public "A.proto";?
>   required string something_else = 2;
> }
>
> // File C.proto
> import "B.proto";
>
> message MyMessage
> {
>   required B.UsesABase my_element = 1;
>
"import public" works exactly like "#include" in C while "import" doesn't.
Here you can't define "optional A.Base a_element = 2" as you only imported
B.proto and you can only use symbols exposed by B.proto. To use symbols
defined in A.proto, you need to import A.proto directly or let B.proto
"import public A.proto".


> }
>
> Given that B imported (contrary to import public) A.proto and used A.Base
> for the definition of B.UsesABase message, is this a legal scenario?
> When would B.proto do a "private import"? Is there any useful scenario if
> the above sample is not legal?
> Why was import public added instead of a "import private" statement with
> import being as it used to be? (like #include in c) and "import private"
> having a new meaning?
>
> I am not sure if I am happy about "import public" at all. To me it looks
> like a "fix in the wrong place", trying to avoid cyclic includes or
> something.
> I also see no profit of this new feature if it comes to generated (c++)
> code: the generated headers still have to be added to the #includes of each
> header file.
> Imho, in both cases, the include list of C.proto and B.proto -> .h files
> looks exactly the same, no matter if B.proto wrote import "A.proto" or
> import public "A.proto".
>
> I guess my tool chain will simply treat import public just like import and
> check for cyclic imports and handle it as if on top of each .proto stood
> "#pragma once" ;)
>
> Constructive comments and scenarios where import public can be beneficial
> are welcome!
>
I think it's that you already implemented "import" the same way as what
"import public" should be (i.e., like #include in c).


>
> Sidenote: Is import "subfolder\XY.proto"; (with backslash) a legal
> statement?
>
>
>
>
> --
> 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 protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at http://groups.google.com/group/protobuf?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to