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:16:38

 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
>