Write the field like this:
  optional .foo.Foo foo = 1;

The leading period tells the compiler that "foo" refers to the foo at the
global scope (i.e. the package), not the foo in the current scope (the
field).  (It's the same semantics and C++ namespaces.)

This is also fixed in version 2.1.0 -- type lookups will no longer resolve
to non-aggregate symbols.  There's a release candidate of 2.1.0 here:

  http://groups.google.com/group/protobuf/files?pli=1

But just using the leading period should work fine.

On Wed, May 6, 2009 at 2:32 PM, Jerry Cattell <jerrycatt...@gmail.com>wrote:

>
> Just wanted to check on this before I open a bug.
>
> Let's say I have two proto files:
>
> foo.proto:
>
> package foo;
> option java_outer_classname = "FooProtos";
>
> message Foo {
>        optional string code = 1;
> }
>
> bar.proto:
>
> package bar;
> option java_outer_classname = "BarProtos";
> import "foo.proto";
>
> message Bar {
>        optional foo.Foo foo = 1;
> }
>
>
> When I try to compile these:
> protoc -I. --java_out=. foo.proto bar.proto
>
> I get an error:
> bar.proto:7:18: "foo.Foo" is not defined.
>
> If I rename Bar.foo to Bar.baz, it works fine.
>
> Is there some sort of collision between field and package names that
> is documented somewhere or is this just a bug?
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@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
-~----------~----~----~----~------~----~------~--~---

Reply via email to