Re: [boost] [RPC] Compile-time reflection for RPC and mocking

Subject: Re: [boost] [RPC] Compile-time reflection for RPC and mocking
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2014-12-08 15:54:01

Thanks Oleg for pointing it out, I remember the discussion about it on
this list for some month.

Is there any documentation available or example we can compile and play
with about your hl library ?

Cheers ;)

On 12/08/2014 09:46 PM, Oleg Labutin wrote:
>    No any questions, currenlty I'd like to say about point. Basically in a
> C++ we should have one mechanism to implement compile time reflection This
> is registering type, and functions-type. And compile time reflection which
> was proposed, in hl library it is only this step by some approaches.
> 
> could I point C++ code
> 
> struct my_reflected_type
> {
>     void (my_function)(int (first), int (second))
>     {
> 
>     }
> 
>     Field(int, my_field0);
>     Field(std::string, my_field1);
> };
> 
> REGISTER_TYPE_SERVICE(classes_stg, my_reflected_type);
> 
> struct my_reflected_type0
> {
>     void (foo)(my_reflected_type (first), int (second))
>     {
> 
>     }
> 
>     void (on_service_call)(my_reflected_type (first))
>     {
>          std::cout << first.my_field0 << std::endl;
>     }
> 
>     Field(int, my_field0);
>     Field(std::string, my_field1);
> };
> 
> REGISTER_TYPE_SERVICE(classes_stg, my_reflected_type0);
> 
> void main_call(std::wstring const& json)
> {
>     my_reflected_type0().call_by_json<foo_accessor>
>        (getjson<my_reflected_type>(json), 0);
> 
>     // here
>     // get boost::v_item<my_reflected_type, my_reflected_type0, 0> classes
>     typedef typename
>           extract<ex<classes_stg> >::type classes;
> 
>     // here
>     // get boost::v_item<foo_accessor,
> boost::v_item<on_service_call_accessor, boost::v_item<my_field0_accessor,
> my_field1_accessor,0> ,0>, 0> accessors
>     typedef typename
>           extract_class <my_reflected_type0>::type accessors;
> 
>     typename
>         find_meth_by_accessor<my_reflected_type0, on_service_call>::type
> accessor;
> }
> 
> 
>      It's really working, without fusion, we can make fields and methods in
> a different scope .
> 
> Thanks
> 
> 2014-12-08 21:50 GMT+02:00 Damien Buhl <damien.buhl_at_[hidden]>:
> 
>> Hi Peter,
>>
>> Were you at the meetingcpp in Berlin ? I also was there, sad that we
>> didn't got in contact, because I've been working on such kind of things
>> for a while now (many years, from compiler plugins for gcc, clang to a
>> c++-only / macro / template metaprogramming version).
>>
>> I would find it nice to see something good solving the issue of remote
>> procedure call and data field synchronization, because I've a
>> not-so-much working solution that I want to opensource at some point
>> when it will be good enough, but it would be of great benefit to get
>> others ideas/impl, because I've been essentially working alone and I'm
>> at the 5th rewrite already. :p
>>
>> In any case I would be really interested on such a library. For example
>> you could use mechanisms like BOOST_FUSION_ADAPT_STRUCT to
>> "automatically" introspects classes in order to generate as well
>> serialized output and function calls. We could even add extensions to
>> fusion to allow more introsprection of adapted types.
>>
>> What I want when I'll get my last changes on BOOST_FUSION_ADAPT_STRUCT
>> working on MSVC too, is to improve it in order to have it automatically
>> generate the boilerplate code to implement compile time reflections
>> proposals to iterate over structs or adt fields, bases etc. And to
>> implement an API near to the proposals ones.
>>
>> I'm wondering how I could use Abel's Sinckovicks metaparse library to
>> improve the emulation for compile time reflection support, so that it
>> don't need to specify fields manually.
>>
>> I think there already is Boost.Rpc in the sandbox, but I feel it didn't
>> evolved much lastly or am I wrong ? Do you meant basing your work on it ?
>>
>> Regarding Boost HPX, I believe they already is an internal library for
>> this kind of automatic remote rpc, did you mean to use their serializers
>> based on spirit and so ?
>>
>> I've always been dreaming of things like : auto remote_obj =
>> std::make_remotely_shared<MyClass>();
>>
>> remote_obj->call_remote_service();
>> remote_obj->remote_field = "assign it remotely";
>>
>> So yes I would definitely love to see others people working on these
>> points, and could even give a hand because I anyway invest weekly time
>> in this topic alone in my cellar :) .
>>
>> Cheers,
>> --
>> Damien Buhl
>>
>> On 12/08/2014 03:27 PM, Peter Bindels wrote:
>>> 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
>>>
>>> _______________________________________________
>>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>