Hi Kenton, I wouldn't go so far as to say the caller *knows* what getValue() will return, but it expects the value to be of a certain type. Errors (including wrong union type expected) are handled later in the same manner as disconnects, so the pipelined call should throw an exception if the type is wrong.
As for separate functions in Getter that return the various types - yes, I guess that would work, but what is the purpose of a union then? I should add that there will eventually be dozens of types in the Any struct, including multiple different interfaces. Creating separate functions for each would greatly increase the amount of code needed, especially on the server side. Since we only use these calls during initialization I guess this isn't all that critical for us, but being able to pipeline unions would just make it that little bit easier to use. Thanks! Johannes p.s. I just reread the C++ Serialization section on unions and realized that calling get for the wrong field returns garbage (i.e., undefined behavior) in non-debug mode rather than throwing an exception as I had assumed up to now. Is the check really such a hit to performance that this change in behavior between debug and release is necessary? If so, it may be better to add an assert rather than an exception in debug mode, otherwise code may suddenly start failing in mysterious ways in release. On Wednesday, May 31, 2017 at 7:58:50 PM UTC+2, Kenton Varda wrote: > > Hi Johannes, > > Thanks for the feedback. > > I'm curious: In your use case, does the caller somehow know in advance > when getValue() is going to return an interface, thus allowing pipelining? > If so, would it make sense to have a separate method, e.g. getInterface(), > for that case, which just returns the interface without the union, thus > allowing pipelining today? Or if the caller does not know in advance, then > what would you like the behavior to be if the caller makes a pipelined > request but the result ends up not being an interface? I guess the > pipelined call should throw an exception? > > -Kenton > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/capnproto.
