I'm not opposed to using a type modifier approach instead of a
separate type. Will we really be adding "arbitrary" annotations to
the objects, or will they be of a specific nature? That is, will we
have modifiers like "fixed", "variable", "extern", etc. be compiler
tokens, or will you just be allowed to add any string you want as a
modifier before the type? The latter would certainly be more
flexible, but would be more complicated as well.
-Bryan
On Aug 21, 2008, at 2:07 PM, David Reiss wrote:
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
