[Gdal-dev] GetGeometryRef in scripts

[Kevin Ruland]

>Perhaps you could clarify where we have problems with gc 
>languages.  I *feel* this isn't a problem, because language
>variables that reference objects should not need to do anything
>at all for objects they don't own.  So, for instance, a reference
>to a geometry that is owned by some other object does not need
>to do any work at all in it's destructor other than check it's
>"owned" flag.  
>
>  
>

Frank,


I had had this nice beautiful description of the nasties complete with 
alusions to the dispicable state of US politics, but after reading 
through the ogr.i code, I wonder if the original source of the problem 
is really my bug in the ogr.i interface description

I see that r1.35 of ogr.i on 8/22 I checked in a change which added 
%newobject to both Layer.GetFeature and Layer.GetNextFeature.  Recall 
that %newobject tells the script that it owns the returned pointer and 
will call the destructor (which is OGR_F_Destroy()).

Could this be the source of the original angst?  It probably isn't 
because chained calls still wont work because you'll end up with a 
dangling reference.  However, it probably does fix my percieved gc 
problem between layer and feature.

Unless Charlie can tell me otherwise, I don't think there is a potential 
gc problem between Datasource and Layer anymore.  The destructors for 
layer are noops so they should be able to succeed after calling the 
datasource destructor.  This is of course dependent on the assumption 
that the datasource reference is maintained during the lifetime of the 
layer.  Charlie has pointed to problems between FeatureDefn and 
FieldDefn, but you have already assumed ownership of this.

I think it would be useful for my sanity if you could walk through ogr.i 
and look at the various methods which create or consume pointers.  Any 
function which returns a pointer owned by the script needs to have 
%newobject.  Any function which assumes ownership of a pointer needs to 
have a DISOWN typemap.  I see that Layer has things like SetFeature and 
CreateFeature, I suspect they should be using DISOWN, but hey what do I 
know.

Alas, I thought it was just last week when I apologized for blowing up a 
very similar issue over FieldDefn (cf. r1.41).

Kevin