Re: [boost] Re: Re: BIL and boost::any

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-01-30 12:09:20

----- Original Message ----- 
From: "Jonathan Turkanis" <technews_at_[hidden]>
> christopher diggins wrote:
>> ----- Original Message -----
>> From: "Jonathan Turkanis" <technews_at_[hidden]>
>> To: <boost_at_[hidden]>
>> Sent: Friday, January 28, 2005 6:00 PM
>> Subject: [boost] Re: BIL and boost::any
>
>>> For instance, a reference-counted any that can bind to anything is
>>> shared_obj<IAnything>.
>>
>> Would it be a reasonable request then to have clone(interface_value)?
>
> Cloning must be introduced at some point. I've been trying to find a way 
> to make
> cloning just another function, but am becoming convinced it's sui generis. 
> Since
> Thortsen uses cloning for his Smart Containers library, I think I'll just 
> borrow
> concepts and machinery from him.
>
> I'm not sure what you mean by "clone(interface_value)", though.

I meant Clone() should be a global function instead of a member function to 
avoid namespace clashes.

I am not sure I understand what you mean by making cloning as just another 
functio. I also don't think Clone is unique. Clone is essentially a call to 
the copy constructor of the object, but there could also be a similar call 
to the default constructor. Conceptually I would group the default ctor, 
copy ctor, and destructor, together. These are the member functions which 
can't be pointed to.

So I would propose (renaming Clone to new_copy):

AnyInterface i = AnyObject;
//...
if (has_copy_ctor(i) && has_dtor(i)) {
   manual_ptr<AnyInterface> p = new_copy(i);
}

also:

AnyInterface i = AnyObject;
//...
if (has_default_ctor(i) && has_dtor(i)) {
   manual_ptr<AnyInterface> p = new_default_ctor(i);
}

Both pieces of code above are extremely useful, especially if we want 
interfaces to have the same expressive power as boost::any. I am currently 
redesigning my Object class in the OOTL, and if I have the two above 
functions, it means that my objects no longer need any special macros. 
(Remember OOTL_DEF_OBJECT?).

>> Would make sense to also have dynamic traits, i.e.
>> is_clonesable(interface_value). This seems to be pointing down a path
>> of never ending feature requests to interface. I think it would be
>> nice to lay down an easily extendible interface type. I mentioned
>> earlier about allowing users to extend interface types. One way which
>> I would like to extend interface types is to have an interface type
>> which provides an extra function:
>
> I don't really understand.
>
>> Usage:
>>
>> dynamic_traits traits = extract_traits(interface_value);
>>
>> dyanmic_traits could be a class which provides run-time functions
>> like:
>>
>> is_copy_constructible();
>> is_default_constructible();
>> size_of();
>> is_primitive();
>> is_integral();
>> etc.
>
> You could determine this stuff (to the extent the language allows) at the 
> time
> of binding, and make it available at runtime.

Do you mean by adding functions to the class? I want to automate the process 
somewhat and remove my dependence on my stupid DEF_OOTL_OBJECT macro. If you 
don't provide this functionality within interface, then I would like to know 
how to create new interface types which do that. I would like to be able to 
create a new interface types, which interject new functions into the 
function tables. I think this ability (to inherit from interface types and 
interject new functions into function tables) should be part of the 
interface functionality.

> However, most of this stuff is
> useful only at compile time.

I showed above how the first two are useful at run-time. size_of() is useful 
when writing code which is type-checked at run-time. It is important for 
making dynamically typed algorithms more efficient. The other two, I can't 
think of applications yet.

>>> I'm thinking of adding a template boost::interfaces::any, which has
>>> (I think boost::interfaces::null might be a better name for
>>> IAnything.)
>>
>> How about IUnknown? It will be especially meaningful when
>> boost::interfaces allow dynamic introspection.
>
> Even when reflection is added, you'll only be able to query the functions 
> of the
> interface; you won't be able to bind the underlying object to an interface
> discovered at runtime -- unless this functionality is built into the class 
> of
> the bound object.

I realize that, but code like:

  int x = extract<int>(null);

would surprise the reader that it works. It is reasonable to expect null to 
contain virtually no extra information, let alone a reference to a live 
object.

The names that I like:

IEmpty
IAnything
IUnknown
INull

best regards,
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org