No subject

[David Abrahams]

This is a multi-part message in MIME format.

------=_NextPart_000_0A51_01C196A8.744D2710
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit



------=_NextPart_000_0A51_01C196A8.744D2710
Content-Type: message/rfc822;
	name="Re_ boost__python, returning new PyObject references.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Re_ boost__python, returning new PyObject references.eml"

Reply-To: "David Abrahams" <david.abrahams at rcn.com>
From: "David Abrahams" <david.abrahams at rcn.com>
To: "Arnaldur Gylfason" <arnaldur at decode.is>
References: <OFA39A1458.C87E8C0A-ON00256B39.005196BC at decode.is>
Subject: Re: boost::python, returning new PyObject references
Date: Sun, 6 Jan 2002 11:11:27 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400


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

>
> > I think your design is more complicated and less clean than it needs to
> be,
> > because either I have failed to communicate to you how I think it should
> go,
> > or you are ignoring my suggestions.
> >
> > I keep trying to push you in the direction of writing a single generic
> > object class with /all/ of the capabilities that are accessible through
> > python's generic interface (number, sequence, mapping, attribute access,
> > call, buffer,...), and then using private non-virtual inheritance to
> provide
> > more-specialized sequence, number, etc. interfaces. Is this suggestion
> > unclear to you? Do you think there's something wrong with it? I'd really
> > like to know.
>
>
> Evidently I misunderstood you. I always thought about object as export ing
> the PyObject_* interface.

What is the PyObject_* interface? Is
    int PyMapping_Size(PyObject *o)
included in it, for example? What are the criteria which decide what's
included?

> When you were talking about inheriting privately from it I was not
thinking
> about an object with all interfaces (PyObject_?, number, sequence, mapping
> and buffer).
> It's not that I think there is something wrong with that.
> The PyObject struct in python is like that so surely it is quite
acceptable
> to reflect that.
> My idea was to have the interfaces separate and then combine them through
> multiple inheritance.
> If we go about having 1 generic object and then specialized interfaces
> through private inheritance we get rid of the multiple inheritance so
> you're probably right that
> it is cleaner.
> The reason I ignored your suggestions was I didn't realise you were
talking
> about an object that had all interfaces.
> Sorry.

No problem. I just wanted to get the communication channels clear.

There is a possible downside to my idea: conversions from, e.g.
object->mapping won't be provided automatically as upcasts by the
inheritance relationship, so you'd need to write implicit conversions.

A possible hybrid approach might be:

struct base
{
     void f() const;
    void g() const;
};

struct F : private virtual base
{
public:
   using base::f;
};

struct G : private virtual base
{
public:
    using base::g;
};

struct H : F, G
{
};

// test code
void f(F const&);
void g(G const&);
void h(H const& x)
{
   x.f();
   x.g();
   f(x);
   g(x);
}

You can think of H, F, and G as object, number, and mapping respectively.
I'm not sure whether this is an improvement, so you should give it a little
thought. I guess one problem with my first suggestion is that there would be
no way to provide the object& -> sequence& or object const& -> sequence
const& conversions.

> This still leaves the issue of the callbacks in mutable_proxy.
> We could change get() and reference() to return just the result of the
> callback, but in the case of get(), the Python reference would be
borrowed,
> since the corresponding
> ref would be a temporary object.

That doesn't borrow a reference. The whole point of ref is that references
are never borrowed, so it never has to worry about how to properly manage
reference counts. A borrowed reference is one whose count is not managed
because you are counting on the lifetime of some other owner to keep it
alive.

> The underlying sequence/mapping still
> would hold it and therefore cause the refcount to be >=1.
> You ok with returning a borrowed reference in get() for mutable_proxy?
> (that would mean m_p in object_base does not have to be mutable).

I guess I don't understand what you're doing again.

BTW, it looks like mutable_proxy has a function for += and =, but not, e.g.,
for -=. Mistake?

-Dave

------=_NextPart_000_0A51_01C196A8.744D2710--