Re: [boost] Interest in runtime concepts library.

Subject: Re: [boost] Interest in runtime concepts library.
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-02-07 09:57:50

On Feb 7, 2011, at 8:43 AM, Germán Diago wrote:

>> It appears that your example is "intrusive" by requiring a typedef ModelOfType in the classes implementing your concept in order to perform the proper 'cast' whereas my implementation is 100% non-intrusive.
> 
> No. It's not. You will be able to do it with a traits class. This
> leaves it as 100% nonintrusive. And you will be able to adapt through
> the model class the interface.
> I mean, you can take a class that says getCapacity instead of
> getCapacityInMB and you can adapt it through partial specialization.
> 
> 
>> It appears that your implementation requires more boilerplate code and provides no ability to define dynamic interfaces such as exposing any object that defines a "concept'" as a json-rpc server or create a json-rpc client based upon a "concept" definition.
> 
> No. It wasn't a goal of my library at all. I must iterate one step at
> a time. My goal is non-intrusive modeling of "interfaces", aka
> concepts. Nothing more, nothing less.
> I want it to play well with boost.concept_check, not a separate
> library, but for now I'm just trying to make it work.
> 
  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).

> 
>> So my question to you, Germán Diago, in what ways is my solution undesirable for your application?
> 
> I didn't know that your solution was targeting the same problem. I'll
> keep an eye on it. My solution tries to be nonintrusive and as
> lightweight as possible.
> As I said, I didn't study yours.
> 
My code is still a work in progress, I have checked my initial code in at https://github.com/bytemaster/boost_dev

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.

> 
>> To implement your example using "boost idl" you would do something like:
>> 
>> namespace idl_definition {
>>        struct DeviceC
>>        {
>>                 std::size_t getCapacityInMB() const;
>>        };
>>        struct IPlugableDeviceC : DeviceC
>>        {
>>                void onOpen();
>>                void onRemove();
>>        };
>> }
>> 
>> BOOST_IDL_INTERFACE( DeviceC,  (),  (getCapacityInMB) )
>> BOOST_IDL_INTERFACE( IPlugableDeviceC,  (IPlugableDeviceC),
>>         (onOpen)
>>         (onRemove) )
> 
> It's more or less the same boilerplate as in my class. A little more
> in mine, but I use operator-> to access the interface. This way, if I
> add two functions, I don't have
> to replicate onOpen and onRemove in the macros. I don't use macros (at
> least for 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.

> 
> 
>> int main( int argc, char** argv )
>> {
>>        IpodDevice ipod;
>>        LegacyDevice legacy_device;
>>        std::vector<DeviceC> devices;
>>        devices.push_back( move(ipod) );
>>        devices.push_back( move(legacy_device) );
>> 
>>        IPlugableDeviceC  plugable_device = ???  I guess I need a way to 'down cast'
>>        devices[0].getCapacityInMB();
>> }
>> 
>> After attempting to implement your example using my API I realized that my solution currently does not provide a down-casting option while maintaining your syntax.  However down casting is possible like so:
> 
> My ModelOfType was specifically targeted at solving the problem. When
> a class is held in a DeviceC, if it models PlugableDeviceC, it will
> instantiate the most-derived model, which
> is the right way to do it (I think). This way you can downcast without problems

Very good idea.  I did not get that from your original description.   Unfortunately, I do not think that can work with my approach because of the requirement to allocate space for all of the function objects.  So my approach certainly has the downside of requiring more memory to allocate 1 function object per in order to gain dynamic implementations of the interface and introspection. 

> 
> 
>> int main( int argc, char** argv )
>> {
>>        IpodDevice ipod;
>>        LegacyDevice legacy_device;
>>        std::vector<DeviceC*> devices;
>>        devices.push_back( new IPluggableDeviceC(move(ipod)) );
>>        devices.push_back( new IPluggableDeviceC(move(legacy_device)) );
>> 
>>        devices[0].getCapacityInMB();
>>        IPlugableDeviceC*  plugable_device =  dynamic_cast<IPluggalbeDeviceC*>(devices[1]);
>>        pluggable_device->onOpen();
>> }
>> 
>> Additionally, my implementation supports public members as part of the 'Concept' which, as far as I can tell, is impossible with your design.
> 
> I don't think it's a very important feature. I could consider to add
> it later, but I think that member functions is more than enough.

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.  

> 
> 
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost