message names and field names must not collide

[lestrrat]

During the course of investigating #79, I ran protoc (libprotoc 3.5.1) against one of the fixtures to find out the "correct" protobuf definition to generate, and I found that definitions like this https://github.com/NYTimes/openapi2proto/blob/master/fixtures/accountv1-0.proto#L321-L327 die with a message like

foo.proto:27:17: "Amount" is already defined in "accountinformationapis.AccountBalance.Data".

After a bit of poking around, I think the rule is as follows:

1: field names and message names may not collide in the same level

This seems to be illegal

message Foo {
   message Bar {}
   string Bar = 1;
} 

$ protoc --proto_path . --go_out=plugins=grpc:pb bar.proto  
bar.proto:6:11: "Bar" is already defined in "bar.Foo".

If we change either the field name or the message name, this goes away

2: if the field is nested, it's not a collision

message Foo {
  message Bar {}
  message Baz {
    string Bar = 1;
  }
}

$ protoc --proto_path . --go_out=plugins=grpc:pb bar.proto 
(no error)

[lestrrat]

So if we're defining the message type for field like this:

properties:
   Foo:
       properties:
           ....

We probably need to declare something like:

message Outer {
   message FooProperty { ... }
   FooProperty Foo = 1;
}

[lestrrat]

Actually in protobuf terms that should probably be -Message?

Or maybe prefix all the parent messages?

message Foo {
   message FooBar {
       message FooBarBaz {}
   }
}

[lestrrat]

Meh, prefixing was a bad idea. -Message seems to do the job

[jprobinson]

Hey @lestrrat, sorry been a busy morning.

In the current version (I believe) we prepend the parent message type to the child type to ensure unique nested message types. What scenario did you run into where this did not work?

[lestrrat]

@jprobinson no, as I looked in the code ,the only prepended types were enums. Message types did not have anything like that. :/

[jprobinson]

I guess that bit got lost somewhere along the way (or I'm just being forgetful, v possible 😅).

Based on your explanations in the other thread, I'm cool with the -Message suffix.