[Cairo] another set of Python bindings

[James Henstridge]

On 13/09/03 02:43, Bill Spitzak wrote:

>On Thursday 11 September 2003 06:26 pm, James Henstridge wrote:
>
>  
>
>>By exposing reference counting operations on cairo_t objects, this
>>particular case would be easy to handle, so that neither the Python code
>>or C code destroy the cairo_t object until both are finished with it.
>>    
>>
>
>Are we talking about cairo "state" objects? Has it been decided that 
>reference-counting the states is necessary?
>
>If not, it seems that the solution is trivial: have 2 python objects, one 
>which destroys the state on destruction, and the other that doesn't. Have the 
>various calls return the correct type.
>
This handles the case of making sure Python doesn't step on the toes of 
some C code, however it doesn't cover the reverse.  If the Python 
programmer has one of thise state objects that doesn't own the 
underlying C object, it may be pointing at an object that has been freed.

Adding a reference count solves both of these issues in a much more 
elegant way.

>If there is reference counts, my recommendation is that there be a "increment 
>reference count" call and a "destroy" call. But there should not be any way 
>to find out what the reference count is, or decrement it without possibly 
>destroying it. This will allow the object to be stored remotely, with only an 
>id number transmitted, and allow them to be shared between connections.
>  
>
Sure.  There is no point in having both a "destroy" and a "unref" in the 
public API.  The object should be destroyed on the last unref.

James.

-- 
Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/