group support

[dweinstein]

@tomas-abrahamsson,

many (albeit internal) google APIs use the deprecated groups feature in protobuf definitions. is there any feeling against supporting this deprecated feature of protobuf? Would it be difficult to introduce support in gpb, or would it introduce other issues that would impact the current functionality? Thanks...

[tomas-abrahamsson]

I'll look into it

[tomas-abrahamsson]

FYI: I think I'm going to do it like this: If we have a message like this

message m1 {
  required group g = 2 {
    required uint32 gf = 3;
  }
}

...then the name of group will be 'm1.m1_g', and there will be a message "invented" for it. The name will not be m1_g because that could possibly collide with some other message definition. Naming it 'm1.m1_g' is safer, I think.

On technical details, I think I will make the internal structure be {{group,Name},Fields} and the field type for such a group (field type for the field g in the example) will be {group,Name}. (The internal structure is exposed via the to_proto_defs compilation option.)

It is not carved in stone yet, I might change my mind later, but for now, I think this is how it will look.

[dweinstein]

sounds a little like protobufjs/protobuf.js#568 (comment)

[tomas-abrahamsson]

Yes, similar

[tomas-abrahamsson]

Hi, I've just pushed a branch, groups if you want to try it out. Let me know how it works for you, and I can merge it to master. Still missing on this branch is nif support, but I can add that later.

I changed my mind about naming, so the group in the previous example would be just 'm1.g' not 'm1.m1_g'. As I learned more while implementing groups, I no longer think there's any risk of naming collision.

[tomas-abrahamsson]

Nif-support is now added, and the branch has been force-pushed. I plan to merge it to master within not too long.

[tomas-abrahamsson]

Support for groups is now included in 3.27.0.