Hi all, I've searched through the Boost mailing list history to find related emails and the last I found was from January where Oleg Labutin and Hartmut Kaiser discussed compile-time reflection in the context of RPC mechanisms. Based on Hartmut's speech last Saturday introducing HPX and explaining a bit about async/future/promise I tried to implement a simple RPC mechanism that uses then to decouple work and the result I have so far is very promising. I have a simple interface with a call that returns a future, and the caller does not distinguish between calling the actual object and calling on a proxy, as both return a future<T>. It does what the discussion mentions - serialize the name of the interface and function, as well as the arguments (basically the mangled name of the interface function) to ensure there are no mismatches. I would like to take this oppurtunity to propose two things: - I can work on this idea to work it out into a full RPC mechanism, to be proposed for Boost.RPC, if there is enough interest. Currently it uses macros to generate and wrap functions, and a simple serializer that serializes in the same way that Protobuf and Thrift also serialize. - Given a compile-time reflection method, the entire proxy class and dispatch class can be auto-generated from the interface class - the full code for registering an interface with the RPC mechanism would collapse to RPC::Register<T>(); To do so, it would need two language additions. It needs access to a compile-time iterator over functions and traits about the argument types, return type, name and whether it is a virtual function. For the prototype this can be manually generated for an interface to show it works. Additionally, it would need to be able to use such a definition to instantiate a virtual function from a base class - basically, hooking up an std::function<X> to a virtual function X directly. I think this is well-implementable (probably reusing most code from lambdas for the link code), but I don't know whether that's true. On the second note, I also proposed a Mock library a few years ago. This basically fell flat on the code that I suggested being very unsafe and using many hackish methods to mock functions. Using the compile-time reflection proposed for the second bullet I would be able to replace the entire hackishness from that with 100% compliant code, with only one minor regression in functionality. That should make it Boost-OK at least from a language standards perspective. Any ideas? Reactions on RPC or Mocking? Best regards, Peter Bindels