Hi Jens, I raised this a couple of years ago in an off-list conversation, and the answer I got was basically that it would be dangerous because Thrift does not have a mechanism for detecting or coping with cycles in graphs of objects. That's true, and that would be non-trivial to implement. However, there are many use cases for trees or other directed acyclic graphs that could benefit from this capability, and in which a cycle would be a programmer error, not something Thrift needed to handle.
BTW, I ended up not using Thrift, mostly for this reason, but I did write a JavaCC-based Thrift parser (called Horatio) that does handle forward references, and use it now to generate Thrift-ish objects, though with a lighter-weight protocol/transport framework, and only for Java and Javascript objects (though the generator is template-based, so you could easily generate anything from the model, including proper Thrift objects). I've been meaning to post it on GitHub at some point -- let me know if you're interested in taking a look at it. Cheers, Bill Dortch On Sat, Apr 13, 2013 at 5:22 AM, Jens Geyer <[email protected]> wrote: > Hi *, > > I know, I read it somewhere but I couldn't find it again, neither in the > code, the whitepaper nor in the Wiki. But somewhere there is a remark or > comment about why recursive types are not supported in Thrift. However, we > frequently run into a situation where we experience the need for such > structures, e.g. with hierarchical data: > > struct treenode > { > 1: string name > 2: list<treenode> childs > } > > Similarly, one could not do things like the following with Thrift: > > struct foo > { > 1: bar somefield > } > > struct bar > { > 1: foo anotherfield > } > > I would really like to see Thrift enhanced here. Especially transporting > hierachical data through a Thrift-based API causes a lot of extra > headaches. So here are my questions: > > (1) Could anyone provide a pointer to the comment or remark I mentioned > above? > > (2) What could prevent us from enhancing the IDL this way? Particularly, > do you see any obious (or not-so-obvious) major problems here with the > parser and the generators? > > (3) Do all supported languages allow such constructs? > > > Thanks in advance for any input you might have, > JensG > >
