Indeed, maps have been brought up repeatedly. I forget the current state of the discussion, but I think it's generally agreed that it would be a good thing to add; it's just a matter of how to implement it (and finding the time to do it).
A couple of the major issues: - backward compatibility with existing repeated fields - ensuring that the client can't change the map key in the mapped value without also updating the map structure. On Wed, Oct 6, 2010 at 11:17 AM, Igor Gatis <igorga...@gmail.com> wrote: > // EXPERIMENTAL. DO NOT USE. > // For "map" fields, the name of the field in the enclosed type that > // is the key for this map. For example, suppose we have: > // message Item { > // required string name = 1; > // required string value = 2; > // } > // message Config { > // repeated Item items = 1 [experimental_map_key="name"]; > // } > // In this situation, the map key for Item will be set to "name". > // TODO: Fully-implement this, then remove the "experimental_" prefix. > optional string experimental_map_key = 9; > > Interesting. It basically pins a field within repeated object to be the > key. I like that. That's very aligned with my ideas. This allows other key > types fairly easily. I guess it would make sense to support string, int and > enum by default. I like the syntax I described better though. :) > > On Wed, Oct 6, 2010 at 12:07 PM, David Yu <david.yu....@gmail.com> wrote: > >> In descriptor.proto, you'll see an experimental map field. It's not >> usable atm. >> In the meantime, you could always simulate a map serialization using a >> repeated message with >> odd field numbers as $key and even as $value (sequential). >> >> On Wed, Oct 6, 2010 at 2:23 PM, Igor Gatis <igorga...@gmail.com> wrote: >> >>> Not sure whether this has been discussed before. In any case... >>> >>> It would be nice to have mapped fields, e.g. key-value pairs. It would >>> work similar to repeated fields, which are implicit maps, e.g 0..N keyed >>> messages. Mapped fields would break from 0..N keys to int or string keys. >>> Integers are very compact and that is very attractive in terms of wire >>> format but settle with integer keys are not really greater than 0..N keys. >>> Thus, string seems more suitable keys of mapped fields. Thus, it seems each >>> item of a mapped field could be defined by the following template-like proto >>> message: >>> >>> message KeyValuePair_of_SomeMessageType { >>> required string key = 1; >>> optional SomeMessageType value = 2; >>> } >>> >>> >>> Let's pick a example. Consider the following messages: >>> >>> message Foo { >>> optional int int_field = 1; >>> ... >>> } >>> >>> message Bar { >>> mapped Foo foo = 1; >>> } >>> >>> Internally, protobuf would read the above code as something like: >>> >>> message Foo { >>> optional int int_field = 1; >>> ... >>> } >>> >>> // Known in code generation time only. >>> message KeyValuePair_of_Foo { >>> required string key = 1; >>> optional Foo value = 2; >>> } >>> >>> message Bar { >>> repeated KeyValuePair_of_Foo foo = 1; >>> } >>> >>> >>> And generated C++ code for Bar would look like: >>> >>> int32 foo_size() const; >>> bool has_foo(const string& key) const; >>> const Foo& foo(const string& key) const; >>> Foo* mutable_foo(const string& key); >>> void put_foo(const string& key, const Foo& foo); >>> void remove_foo(const string& key); >>> const RepeatedPtrField<string>& foo_keys() const; >>> const RepeatedPtrField<const Foo&>& foo_values() const; >>> >>> >>> Thoughts? >>> >>> -Gatis >>> >>> -- >>> 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<protobuf%2bunsubscr...@googlegroups.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/protobuf?hl=en. >>> >> >> >> >> -- >> When the cat is away, the mouse is alone. >> - David Yu >> > > -- > 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<protobuf%2bunsubscr...@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.