I agree that a new first-order type is not the best way to go there. A "variable integer" isn't a different type than an i32 or an i64, rather it's a specification of how you want a protocol to handle transporting the integer. How to encode/decode a type is different from what the type is. I personally feel very strongly that we should strive to avoid type-bloat in Thrift. Adding one new type or custom field here and there seems very simple to those of us already familiar with the project, but it all adds up over time and costs the project by making it less approachable for new users/developers.
I agree with David (and I think Chad has also been suggesting the same thing) that we should extend the Protocol abstraction to support type annotations. This way, we keep the number of types small and approachable, but allow for greater flexibility in protocol implementations. The API would change from something like: void writeI32(int) int readI32() To: void writeI32(int, hints) int readi32(hints) The default implementations can just ignore the hints entirely, keeping things as simple as they are today. Advanced implementations can require usage of the hints. Cheers, Mark -----Original Message----- From: David Reiss [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2008 2:07 PM To: [email protected] Subject: Re: Adding a "vint" type to Thrift 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 >
