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
>
