[C++-sig] generic object wrappers

[Arnaldur Gylfason]

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

I believe many of the abstractions in operators are clear to those used to
mathematical
language, esp. abstract algebra. For those object<ring> would be clear and
might be considered superior to object<addable,subtractable,multipliable>.
Those who find it unclear could happily ignore these combinations. This is
not important though.

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

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

     ...

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

Yeah I meant to add that maybe you needed it in other parts of
boost.python.
Sadly, I must admit I have not taken a look at other parts and can't
comment on
them at this stage.
All in all I believe this design is good and 1 case where it will benefit
you (or me)
is enough to warrant it.

Regarding typecasts, yes they're ugly. Inside a concrete object wrapper
like list it should
be safe though. Using a reinterpret_cast makes the typecasts obvious in
code.
After downcasting to a PyListObject* I could build a
reference<PyListObject*> and benefit
from automatic conversions after that yes, but the usage I had in mind was
just touch and go,
i.e. there wasn't really any need of keeping a PyListObject*, I just needed
the typecast
to access an attribute for the PyListObject instance (obitem).
I think most uses of these typecasts/conversions in the object interface
part are similar to that.

Don't get me wrong though. It is quite possible I will find out that this
design comes in handy
later.

Cheers

Arnaldur