First, I don't understand why it would be limited to 64-bit. What if I have an integer that I want represented as 32 bits in memory but serialized with a variable-length encoding.
Second, I wonder if creating a new type is the best solution. I've been thinking for a while that it might be useful to add arbitrary annotations to types. We already have a few special cases of this (cpp_type in C++, slist in Erlang), and vint would be a third. I think it might be time to bite the bullet and implement annotations so we can stop adding new syntactic constructs for each minor extension to the data model. --David Bryan Duxbury wrote: > All, > > We've been following the discussion on THRIFT-110. I think as a first > step we should add a "vint" (variable integer) to Thrift. > > My general proposal is that we add vint as a new type. Protocols that > don't do variable length integers can treat vints as i64s. Protocols > that do implement variable length integers can choose encodings that > make sense for them. > > We'd have to change the compiler and all the generators and libraries > to recognize vint, if for no other reason than to treat it as an i64. > However, this would make implementing other protocols that included > variable length integers very easy. > > Are there any objections to this proposal? If not, I'll make an > issue, and Rapleaf is willing to commit time to this enhancement. > > -Bryan >
