That's fine, but if we do that, I'd prefer to see it implemented with a flexible syntax and then check validity after parsing.
--David Mark Slee wrote: > I'd propose starting with a fixed set of type hints that we agree upon. > We could certainly implement a dynamic any-string goes type of thing. > But here's my concern with that: > > 1/ If we agree upon a fixed set of modifiers, we're more likely to get > them implemented across more languages since deciding on the set will > involve getting some basic agreement amongst the Thrift community. We're > likely to retain more overall compatibility. > > 2/ If the modifiers are dynamic, it implies that people would make their > own local changes, and write their own custom Protocol implementations. > We're more likely to duplicate this work or disagree on things. This > will make custom protocol submissions back into the trunk more > difficult, and the core project becomes more likely to lose quality > work. > > So, while a dynamic implementation is arguably more elegant/flexible, I > think having the community agree upon a reasonable set of type > annotations is most healthy for the coherence of Thrift in the long run. > > Cheers, > Mark > > -----Original Message----- > From: Bryan Duxbury [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 21, 2008 3:40 PM > To: [email protected] > Subject: Re: Adding a "vint" type to Thrift > > 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 >>> >
