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 times, either by using two repeated
> fields, or a repeated field of a custom "pair" type. In these cases, it
> would have been nice to be able to use the Protocol Buffer as a map
> directly, rather than needing to transfer the data to some other object that
> actually implements the map. I would be interested to hear the opinion of
> the Google maintainers. I'm assuming that there are probably many
> applications inside Google that exchange map-like messages.
> This would be a big change, although it wouldn't be an impossible one, I
> don't think. I think it could be implemented as "syntactic sugar" over a
> repeated Pair message.
The syntactic sugar is what I meant by implementing it with repeated pairs.
> I think the biggest challenge is that maps are a "higher level" abstraction
> than repeated fields, which leads to many design challenges:
> * Are the maps ordered or unordered?
> * If ordered, how are keys compared? This needs to be consistent
> across programming languages.
> * If unordered, how are hash values computed? This could result in a
> message being parsed and re-serialized differently, if different languages
> compute the hashes differently.
Actually, I have a different opinion. High level is not a problem. It's a
dictionary, e.g. string -> object. It does not matter whether the list is
ordered or not. It does not matter how the hash is computed. Serialization
is simple: list of Pairs. The it does not matter the order.
A given implementation may decide to read each pair at a time and insert it
into a hashmap. The down side is that a big list will cause hashmap to grow
many times. A solution could be reading the flat list to figure out what the
size is, then create a map out of it.
* For both, how are "'unknown" fields handled?
> * Do the maps support repeated keys?
> * If not, what happens when parsing a message with repeated keys?
Hm... I'd say no. Simple (unique) string to object seems to fit lots of
people needs. Perhaps, thought, values could be repeated. But that is easily
achieved by a wrapping message which has a repeated object.
> Other message protocols contain map-like structures: JSON, Thrift, and
> Avro. Avro only supports string keys. JSON only supports primitive keys.
> Thrift has a similar note about maps:
> For maximal compatibility, the key type for map should be a basic type
>> rather than a struct or container type. There are some languages which do
>> not support more complex key types in their native map types. In addition
>> the JSON protocol only supports key types that are base types.
> Evan Jones
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
For more options, visit this group at