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.

Reply via email to