Good to know. In this case, I'm actually not looking for something optimal in terms of efficiency. The data structures I'm passing in are small and the services I'm calling are coarse-grained so the transport+marshalling costs should be relatively insignificant compared to what happens in the service. In other words, I'm optimizing for convenience and descriptive interfaces over cpu/memory/bandwidth.
alex On Mon, May 3, 2010 at 9:22 AM, Mayan Moudgill <[email protected]> wrote: > > Yes, you can use unions. This _DOES_ not correspond to list<any>, but to > union A { > ... > } > list<A>. > > So, how are unions implemented? > > > Consider: > union Any { > 1: i32 v_i32 > 2: double v_double > }; > > > In C++ this will become a class with fields > class Any { > int32_t v_i32; > double v_double; > > struct __isset { > bool v_i32; > bool v_double; > } __isset; > } > In other words, memory-wise, this is really a structure > > Python: > class Any: > def __init__....: > self.v_i32 = ... > self.v_double = ... > Also a struct > > It may be different in some of the other languages, of course, or in > v0.3.0, but I'm not sure that the "union" suggestion is that efficient. > > > > Alex Boisvert wrote: > >> On Mon, May 3, 2010 at 7:09 AM, Bryan Duxbury <[email protected]> wrote: >> >> >> There is already a totally viable workaround, though - make a Union of >>> the >>> types you want in your collection, and then make the field >>> list<YourUnion>. >>> You get basically all the capabilities with very few drawbacks, plus the >>> ability to include multiple logical "types" in the collection, not just >>> physical types. Of course, if you literally need "any" possible object to >>> go >>> into the collection, then this won't do it for you. >>> >>> >> >> Thanks for the suggestion, Bryan. >> >> I'm experimenting with marshalling my values to strings (I only deal with >> basic types such as int32, int64, strings) right now. If that doesn't >> work, I'll go with your suggestion. >> >> alex >> >> >
