On Thu, Oct 7, 2010 at 6:19 PM, Jason Hsueh jas...@google.com 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
On Thu, Oct 7, 2010 at 7:02 PM, Igor Gatis igorga...@gmail.com wrote:
On Thu, Oct 7, 2010 at 6:19 PM, Jason Hsueh jas...@google.com 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
On Thu, Oct 7, 2010 at 11:18 PM, Jason Hsueh jas...@google.com wrote:
On Thu, Oct 7, 2010 at 7:02 PM, Igor Gatis igorga...@gmail.com wrote:
On Thu, Oct 7, 2010 at 6:19 PM, Jason Hsueh jas...@google.com wrote:
Indeed, maps have been brought up repeatedly. I forget the current state
of
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
On Oct 6, 2010, at 9:23 , Igor Gatis wrote:
It would be nice to have mapped fields, e.g. key-value pairs.
I think that map support would probably be useful. I've basically
created my own maps in protocol buffers a couple times, either by
using two repeated fields, or a repeated field of a
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
On Wed, Oct 6, 2010 at 11:40 AM, Evan Jones ev...@mit.edu wrote:
On Oct 6, 2010, at 9:23 , Igor Gatis wrote:
It would be nice to have mapped fields, e.g. key-value pairs.
I think that map support would probably be useful. I've basically created
my own maps in protocol buffers a couple
// 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 {
//
