Re: [protobuf] Re: Import statement semantics

[Josh Humphries]

The "public" and "weak" import modifiers are in no way similar to anything
in C++.

A "public" import means that all imported symbols are "transitively"
imported into dependees. It's a little hard to describe, but easier to
understand with an example:

Let's say we have three files.

   1. foo.proto: This file defines message foo.Foo.
   2. bar.proto: This file defines message bar.Bar and imports *public*
"foo.proto".
   3. baz.proto: This imports "bar.proto".

Normally, the import in baz.proto (bullet 3) means that the contents of the
baz.proto file can freely refer to symbols defined in the imported file --
namely, bar.Bar.

However, because the imported file *has public imports (*namely,
foo.proto), it's as if baz.proto imported foo.proto, too. So not only can
baz.proto use the symbols defined in its imports (e.g. bar.proto), *but
also* all of the symbols that are *publicly* imported therein. So, in the
example, the contents of baz.proto (bullet 3) can refer to the symbol
foo.Foo *without * actually importing foo.proto, thanks to the public
import in bar.proto.

Does that make sense? It's like the "public" keyword takes all symbols from
the imported file and adds them to its own set of exported symbols.

There is a brief bit of doc on the main website for public imports. Perhaps
it explains it better than me:
https://developers.google.com/protocol-buffers/docs/proto#importing-definitions


A "weak" import is very different. A weak import is one whose contents are
only *weakly* required. I think the actual implementation varies from
language to language (IIRC, some languages do not even support weak
imports, treating them instead as normal imports). I believe the idea is
that generated code will not have a strong compile-time dependency on the
generated code/library for the imported file. IIUC, fields whose types are
defined in weakly imported files will be treated like unknown fields if the
runtime type is not available (e.g. not linked in).

Despite this being documented

as if supported in the C++ library, I think it's intentionally

 not

supported

in the open-source library (along with lazily-parsed

fields
).
So it's part of the grammar, but perhaps disallowed in practice (or, more
likely, ignored and treated as a normal import).


*Josh Humphries*
jh...@bluegosling.com


On Tue, Dec 4, 2018 at 5:00 PM Michael Powell  wrote:

> On Wed, Nov 7, 2018 at 4:28 PM Michael Powell 
> wrote:
> >
> > Hello,
> >
> > Is there some documentation concerning import semantics?
> >
> > For starters, I assume that you specify the path. This may be further
> > enhanced by specification of an "import path", not unlike in C++
> > wherein you may specify include, library, etc, paths.
>
> I have not received any clarification for this. Can someone please
> clarify? I want to think in terms of C++ access modifiers, private,
> protected, public, etc, but I'm not positive this is analogous, or
> what the ramifications ought to be when "linking" across .proto files.
>
>
> http://developers.google.com/protocol-buffers/docs/reference/proto2-spec#import_statement
>
> > Second, what is the impact of "weak"? "public"? Or an unspecified
> modifier?
> >
> > Thanks!
> >
> > Best regards,
> >
> > 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 protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> 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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Re: import statement

[Jason Hsueh]

You typically want to specify imports relative to your "project root", and
run protoc from that directory. Then the includes would be generated
as #include
"pathCommon/CommonMsgs.pb.h" (I'm assuming you have your project's root in
the include path for your compiler)

On Fri, Sep 24, 2010 at 9:58 AM, LakeshoreGuy wrote:

> I can add pathCommon to my compiler's include path to solve the
> problem.  Previously it was only part of the protoc include path
>
> There may be more issues here than I realize, but it's inconvenient
> that the generated function uses the filename AND the path, seems like
> filename should be sufficient.  If this were the case I could add the
> path to the import with ".." and that would also work with the include
> statement.
>
> Jason
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.