Thanks Bill,
based on your answer I searched the mailing list archives and found a number
of discussions. Very helpful.
Interestingly, most of the use cases that pop up every now and then seem
indeed to deal with data organized in trees ... looks as if we really should
think about it. From what I read so far, improvements in that area could add
real value to Thrift.
BTW, the comment I was looking for is here:
http://markmail.org/thread/4pwhw5d254zrphv5
Regards,
JensG
-----Ursprüngliche Nachricht-----
From: Bill Dortch
Sent: Saturday, April 13, 2013 4:08 PM
To: [email protected]
Subject: Re: Recursion in structures
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