search

microsoft / bond

Bond is a cross-platform framework for working with schematized data. It supports cross-language de/serialization and powerful generic mechanisms for efficiently manipulating data. Bond is broadly used at Microsoft in high scale services.
MIT License
2.62k stars 322 forks source link

Add support for structs as map keys #149

Open jordanelder opened 8 years ago

jordanelder commented 8 years ago

I am working on a schema in which Guids are used as the keys in maps. I am doing this by creating a type alias between Guid and string, and using a BondTypeAliasConverter class to convert them.

I would like to be able to use the Bond.GUID struct as a map key instead of a string, so that the binary serialized output is more compact.

lalo commented 8 years ago

Related to #133

chwarr commented 8 years ago

We've kicked this idea around a couple of times, but we always end up getting stuck on how/whether to implement things like hash code computation, equality comparison, operator<, &c. on Bond structs. Doing so would be mechanical but there are enough cases where the mechanical implementations aren't the right thing to do.

A middle-group approach would be to allow blobs as keys. Then, with use of type aliases, maps/dictionaries with non-scalar keys could be constructed. This would enable efficient representations for many structs, but put the burden of conversion to/from objects and the selection and implementation of hashing/comparison algorithms on the user of Bond.

Would that be enough for your cases--or does it leave too much up to you?

jordanelder commented 8 years ago

133 will solve this problem for Guids. There isn't a pressing need for other structs as map keys at this point, but it may eventually come up. Thanks!

nehulyadav commented 8 years ago

@chwarr The middle approach seems reasonable since maps/dictionaries have O(1) access, insert and delete time. I am trying hard to implement it. Could you explain the approach a little in detail from an implementation standpoint?

chwarr commented 8 years ago

@nehulyadav, not sure whether the middle approach is the actual way to go. Haven't done much thinking in this area lately.

Off the top of my head, the following changes would be needed: