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

Subject: Re: [boost] [RPC] Compile-time reflection for RPC and mocking
From: Oleg Labutin (ol.labutin_at_[hidden])
Date: 2014-12-08 16:29:34

Thanks ;)

2014-12-08 23:16 GMT+02:00 Oleg Labutin <ol.labutin_at_[hidden]>:

>  Currently hl availble on https://github.com/hl-plus/. And certain module
> in which used compile time reflection is
>
> https://github.com/hl-plus/hl/blob/master/include/hl_ipc/luna_service_backend.hpp
>    (Obviously register_service(Service* svc) should be called for all
> sevices by iteration type list.)
>
>    But I guess it very specific and related to luna (dbus based calling)
> service. And I hope, I can make more suitable for explanation simple
> project for demostrate tomorrow.
>
>     Thanks
>
> 2014-12-08 22:54 GMT+02:00 Damien Buhl <damien.buhl_at_[hidden]>:
>
>> 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
>> >
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>