Re: [boost] Interest in runtime concepts library.

Subject: Re: [boost] Interest in runtime concepts library.
From: Germán Diago (germandiago_at_[hidden])
Date: 2011-02-07 10:20:57

>  I need to study boost concept check better, but I believe that concept checking was one of the goals of 6 year-old Boost Interface Library.   Or did you mean to say that you wanted boost concept check to validate your interfaces as conforming to the concept. There is a good possibility that my design (public function objects) would have more difficulty conforming to concepts than yours (public member functions).

If you are following the c++0x standarization process, you know that
there was a concepts proposal that finally went out of the standard.
This is what Boost.ConceptCheck tries to workaround as a library.
But there's a piece missing. Concepts are a compile-time feature. I
want that classes covering those compile-time concepts can be stored,
without knowing the type and without requiring inheritance.
So, the goal of my library is the runtime part of the compile-time
feature called concepts that were to go inside c++0x.

> I recently modified my interface to support custom transformations of the interface via a template parameter.  My idea was that I would implement a few initial transformation:
>
>        mirror_interface       - exposes the un-modified interface.
>        async_interface       - converts all return types into futures<return_type>
>        const_interface        - only exposes const methods.

I think that the goals of your library are broader than those of mine.
I just want that compile-time concepts can be held in a runtime
object. That's my primary goal now.

> I don't like the use of macro's, but one of my design goals was to provide reflection on the interface and macro's are the best way to ensure names stringize properly and to reduce boiler plate code.

Ok. There's no choice then. But reflection is not one of my goals for
now, so I did it without those macros.

> Obviously we have a different set of requirements.  My question becomes, do our requirements conflict with each  other or is there some overlap where we can work together for a more powerful/general solution.   I hope my previous e-mail was not interpreted as being critical of your code or too self-promoting of mine.  I am really just interested in feedback and to understand what people would want in such an interface and what design choices are 'deal breakers'.  I was encouraged to see your e-mail because it suggests that there is an independent need for some type of solution here.
>
> For example, I could modify the code generated by the macro to make the interface class inherit base classes that implement the method name instead of using member function objects.

I think your design, as I said, targets more features than mine. Think
of my library as an extension to get rid of object-oriented
programming. Instead, the goal is to be able to use concepts from
boost.conceptcheck and to be able to hold objects that represent those
concepts at runtime. After that, I want that these concept classes to
integrate with the language as well as I can.

I want them to play well with shared_ptr. Specifically, I would like
to be able to point with a shared_ptr<BaseConcept> to a
shared_ptr<RefinedConcept>. I want to be able to use c++ references
to point to concepts. I can already do it:

IpodDevice dev;
DeviceC my_device(move(dev)); //It's holding a PlugableDeviceC, in
reality, so I can downcast.

PlugableDeviceC & dev_ref = my_device.castTo<PlugableDeviceC>();

IpodDevice dev2;

PlugableDeviceC my_device2(move(dev2));

DeviceC & my_device2_ref = my_device2; //Automatic (and safe) implicit
conversion.

My goal is a library that integrates with generic programming giving a
runtime counterpart.