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:
>
> http://wiki.apache.org/thrift/ThriftTypes
>
> 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
>
> --
> Evan Jones
> http://evanjones.ca/
>
>
--
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.
