> At least if you expect java to be installed on the system it can't be > much easier than that ;) It's been my experience that it is easier to get a stable lexx/yacc/g++ working on a Linux system than Java. And for distributions that use binary packages, the runtime requirements for the Thrift compiler are miniscule.
> On the > other hand I would imagine > that implementing new languages would be much easier with a clean > templating approach. I'm not sure that I agree with this. If the Thrift data model were simpler (which I usually wish it were when working on the compiler), then I think this would work well, but my experience is that the amount of special-case code required to generate stubs as versatile as Thrift's is quite large and could not be succinctly expressed by templates. I would love to be proven wrong on this point, though. Regarding hash codes, I think they would complicated the data model and make it more difficult to visually parse binary dumps of structures. Also, check out the output of thrift_dump in contrib/. That would also be less readable. Finally, the codes would be larger and would not lend themselves as well to the variable-length encoding used in TDenseProtocol. I think inheritance complicates the data model without adding much value. If we were going to do it, I'd want to do it like Protocol Buffers do, which is basically a #include. (We'd have to have better checking for things like duplicate field ids.) This could be done by the parser and instantly work in all languages. > Now you focused more on the optional/required and so on. Indeed all > correct. But my focus was more on the fact that ab can be derived from > a and b. That means that even old struct implicitly have ab. So when > you make the switch you either have support this logic in (every) client > or you switch over to only rely on ab and can no longer read older > structs. > > See what I mean now? My understanding is that you want Thrift to generate code for combining values? This would basically make it a programming language, and we are not going to be doing that. > Well, if you only use Thrift for serialization and versioning you > might not > always have a need for the service stub generation. While this isn't > really a big problem I am wondering if these aren't two separate things. If you don't declare any services, no stubs will be generated. --David
