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 15:46:27

   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
>