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 08:43:50

> 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.

> 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.

> 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).

> 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

> 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.

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