[C++-sig] generic object wrappers

[David Abrahams]

> <<<
>
>    > I've looked at mpl and am comfortable using it. I feel we should
>    > use it while in development and not worry about rewriting stuff
>    > unless mpl will not be officially in boost when the boost.python
>    > rewrite is ready.
>
>    Agreed. It might be choking one of my most important targets, but
>    I'm not sure yet. I hope not.
>
> >>>
>
> It's an experiment (an interesting one). It either works or not.

It works! believe it or not, EDG was choking on the PREPROCESSOR
library construct, so Aleksey just checked in an alternative.

> If it works the interface to users will be relatively straight
> forward.  The complexity will be hidden from them in the
> implementation.  Even if we have to rewrite things, it won't take too
> long.  (Maybe you were referring to something else?)

No, that's OK: I was just "in a mood", I guess.

> <<<
>
>    > We have discussed sets of capabilities like integral, etc. I was
>    > wondering if we should pick a few concepts from boost.operators
>    > as sets of capabilities.
>
>    Well, I'm beginning to wonder if this is all too complicated to be
>    worthwhile. If not, that would be my fault :(.
> >>>
>
> I don´t think so. Again, complexity should be hidden from the user.
> Also my comment above shouldn't make things complicated. It´s for
> convenience.  In operators you define addable, subtractable etc. same
> way we aim for the capabilities.  So maybe it makes sense to define
> sets, like additive, arithmetic, ring etc. just as in operators.

Maybe. I find all of those combinations in operators.hpp a bit
daunting, but I'm sure that some people find them indispensable.

<snip>

> This looks neat!  Just to be sure, reference<MyListSubtype>::get()
> would return a reference_proxy<MyListSubtype> which inherits from
> reference_proxy<PyListObject> which inherits from
> reference_proxy<PyObject>.  It would thus provide automatic
> conversions to PyObject*, PyListObject* and MyListSubtype*, just as if
> they were related through C++ inheritance.

Precisely!

> I have been thinking about its use though.  In the generic wrappers
> I only work with PyObject* and don't need anything else.

I would find it useful; there's quite a bit of casting involved in
some of the newest code. I always intended that Boost.Python would be
good for users who want to create a new extensioni type directly
(rather than wrapping some C++ type). In other words, Boost.Python
should be a framework, with the high-level parts easiest to use but
with lower level facilities which still help you write effective
Python components in C++. Your work falls in the middle area.

> In concrete objects like list, we know the type and can safely
> typecast to PyListObject* if/when needed (I did that in the iterator
> support).

Typecasts are dangerous and ugly, though.

> The Python C API always work with PyObject*, even in
> functions working with concrete types like list.  The PyObject*is
> converted to PyListObject* within the function.  If we would have
> API functions for PyObject*, PyListObject* (and MyListSubtype*)
> etc. I could see direct benefit from the design
> above. reference<T>::get() would pass in all cases.

Don't forget, once you downcast to PyListObject*, you can build a
reference<PyListObject*>, use that, and all casting disappears.

> If you want to provide interfaces for different specializations of
> reference<T> and provide implicit convertibility on that level, the
> design would help.  function f(reference<PyListObject>) could then be
> called with a reference<PyListObject> and reference<MyListSubtype>.  I
> did not foresee many interfaces that work on the reference level
> though.  E.g. rather than f(reference<PyListObject>) I would have
> f(list).  a MyListSubtype would be used as a generic object
> (object<indexable,...>) but the automatic conversion to list would
> call PyList_Check and pass it. Thus the function f can be called on a
> MyListSubtype.
>
> I am probably out in the wild. I'm just trying to imagine usage of the
> above design.  Please tell me what usage you had in mind.

Your reasoning is sound, but you may have overlooked cases like
boost/python/object/class_wrapper.hpp and
libs/python/src/object/class.cpp.

Maybe those cases aren't common enough to warrant such a feature.

-Dave