// 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 <[email protected]> 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 <[email protected]> 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 [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<protobuf%[email protected]>
>> .
>> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
