boost::python, returning new PyObject references

[David Abrahams]

----- Original Message -----
From: "Arnaldur Gylfason" <arnaldur at decode.is>

> Sounds good.
> The general case has to be easy. OK to have the option of total
> fine-grained control when needed.

Yep.

> > OK. I think it would be good to do it in terms of the concepts we've
been
> > working with, though. The generators, for example, will make it much
> easier
> > to transition to a type_list-configurable system. We could imagine a
> > protocol like this one:
> >
> > template <class T, bool checked, class Base>
> > struct indexable_generator : Base
> > {
> >    ...
> > };
> >
> > where "checked" determines whether the capability is enforced at
> > construction time. Then you can define your sequence, mapping,
number,...
> > and concrete list, dict, integer... types in terms of them
>
> Sounds reasonable. Would we add the type member template then when
starting
> with mpl or is it not necessary for meta-programming?

I'm not sure what you mean by the "type member template". Maybe you mean the
nested type "type". Whoops, I realize that I erred. We'd need a formulation
that can be used with metafunctions:

template <class T, bool checked, class Base>
index_capability : Base
{
    proxy operator[](...
    ...
};

// this part can be left out until you use mpl
struct indexable
{
    // apply is the analogue to operator()()
    template <class T, bool checked, class Base>
    struct apply
    {
        // this is its return type
        typedef index_capability<T,checked,Base>::type type;
    };
};

Does that answer your question?

>
>
> > Yes, I was thinking about that but didn't address it. It is handled
> fairly
> > easily with a templated constructor in object<>. You do need to
> > STATIC_ASSERT that the capabilities are a subset. Easy enough using mpl.

Do you understand this part, at least abstractly?

> > However, since the capabilities will remain relatively static, you might
> > think about a simpler approach for now which uses a collection of
> > BOOST_STATIC_CONSTANTs in a bitmask arrangement. Each generator might
> define
> > its bitmask values, and they would appear combined in the most-derived
> > class.
>
> Don't quite get it. Sorry.

How many slots are there? N. Now suppose we embed (N+15)/16 = M compile-time
constants (e.g. enums) named slots1...slotsM in each capability template.
Each one adds a single bit to the constants defined by its Base parameter.
Then the assert becomes easy: the templated constructor just checks for I =
1 to M to be sure that (self::slotsI & ~Other::slotsI) == 0.

> > > It seems to me then that the objects are not connected then (apart
> > > inheriting from individual generators, so they both pass as
> > > indexable_generator etc.)
> >
> > I don't get what you're saying here.
>
> Has to do with the inheritance above.
> object<A,B,C>:
> o == object<A,B,C>
>
> empty - A<o> - B<o> - C<o> - o
>
> object<A,C>:
> o2 == object<A,C>
>
> empty - A<o2> - C<o2> - o2
>
> What is the relationship between o and o2?

None. You can't rely on inheritance to do this conversion. That's why you
use templated construction and assignment.

-Dave