On Thu, Oct 7, 2010 at 6:19 PM, Jason Hsueh <[email protected]> wrote:
> 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 > I believe this has been addressed by the proposal I have made. Maps a repeated fields. So they can be exposed as list of pairs (string, message). > - ensuring that the client can't change the map key in the mapped value > without also updating the map structure. > Could you provide an example? > > > On Wed, Oct 6, 2010 at 11:17 AM, Igor Gatis <[email protected]> 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 <[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]<protobuf%[email protected]> >> . >> 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 [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.
