Definitely not proposing we add a primitive tree type or other such nonsense. :-)
So your example Node struct is more or less what I want although my data structures are more DOM-like and can be nested in interesting ways deep in the tree. Ben's index based-representation can certainly capture the data but it will make it extremely awkward and unnatural to manipulate. It's a bit like the tricks used to map trees into relational databases. We only use them for want of a more explicit representation of the actual relationships because it can twist the data model into a less intelligible form that is ultimately a lot harder to maintain and evolve. As to the risks, creating a cyclic reference should just be considered an application bug. It'll probably crash with a stack overflow or similar runtime error. This ought to be a very familiar problem to programmers. If they're using trees anyways then the potential for this bug probably already exists elsewhere in the application too. Nothing new or surprising there. :-p Supporting recursive types will also help Thrift be more interoperable with other serialization formats like JSON and Xml. Not sure if that matters much but I can see it being useful for some folks. For example, it becomes completely straightforward to write a routine to transform an Xml schema into equivalent Thrift or vice-versa. Of course the transformation can still be done without supporting recursive types but it would be hell to use... Sorry for rambling on here. :-) Jeff. On Tue, Mar 2, 2010 at 3:28 PM, Mark Slee <[email protected]> wrote: > I don't entirely follow what you're suggesting in 3(c). You say that: > "self-referencing types can only be used in Thrift list<T>, set<T> and > map<K, V> fields" > > How exactly does this work? Are you suggesting that we'd just allow > something like the following? > > struct Node { > i32 value; > list<Node> children; > } > > This feels a bit risky to me, and we'd still run into recursive issues here > if a node was attempted to be added to its own children list and deep-copied > (though I guess this is an application problem that the author can avoid). > > I definitely don't think we should make "tree" a primitive type in Thrift, > given that there is not a canonical tree representation in most target > languages. I also don't think representations like Ben's are so bad for wire > transport. > > Cheers, > Mark > > -----Original Message----- > From: Jeff Brown [mailto:[email protected]] > Sent: Tuesday, March 02, 2010 11:49 AM > To: [email protected] > Subject: Re: Trees in Thrift. > > What if we start with 3c first since it shouldn't require any significant > changes across the board, even in C++, then look at 3b? > > As for using a language-specific annotation for references, I'm not sure > that's a great plan. After all, this has more to do with how the language > binding is implemented rather than anything special about the language > itself. Someone could conceivably implement the same compositional > behavior > in a C# language binding as in the current C++ language binding and the > code > generator would need to adapt in the same way by choosing to use a pointer. > > I think language-specific annotations make more sense for specifying things > like namespaces, changing the style of the generated code, or overriding > the > raw data types to use (eg. to replace std::vector with some other vector > type though I am not proposing that we add such an annotation). > > Jeff. > > On Tue, Mar 2, 2010 at 9:37 AM, David Reiss <[email protected]> wrote: > > > I think 3b is actually not that hard. I would prefer to do it as an > > annotation, > > rather than new syntax, since it is C++-specific, as far as I can tell. > > The > > C++ code generator actually already has support for generating structs > with > > pointers to each field (this is how RPC argument structures work: they > have > > pointers to the actual arguments). We'd just have to generalize it to > work > > on > > a field-by-field basis. Personally, I would prefer to use auto pointers > > over > > raw pointers with a destructor, but the latter is a shorter distance from > > where > > we are now and would be a good first cut. > > > > I think the problems blocking this feature are more organizational. We > > (the > > maintainers) have to decide whether we want to commit to making tree > > structures > > a supported construct in Thrift, do the actual implementation, and figure > > out > > what to do with languages that aren't being actively supported. > > > > --David > > >
