----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com>
christopher diggins wrote:
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com> To: <boost@lists.boost.org> 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