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 >
