[Gdal-dev] GetGeometryRef in scripts

[Kevin Ruland]

>Kevin,
>
>I don't really see that this is practical.  Even if we have a "free"
>geometry we don't know that we ought to use SetGeometryDirectly()
>since we don't know whether the script will continue to use the
>geometry reference later. 
> 
>  
>

Frank,

Ah another complexity, a single free geometry can only be the argument 
of one *Directly call.  This stuff is certainly not easy.

>I am depressed by this whole concept of bending over backward
>to support chaining.  I seems wrong to do all this backward referencing
>of objects and I feel like it will one day make us all sorry.  
>
>  
>
I can't say that I too am depressed ... a better description would be 
"frustrated," although I completely sympathize with your feelings.  It 
seems the more friendly we try to make it the more complex its going to 
become and eventually the bindings will become soooo complex that only I 
can maintain them.  In which case you're actually worse off than before :)

The current swig bindings have some short falls but I do believe they 
are fairly useable provided the developer follow the guidelines of the 
underlying C++ library.  The rules in a nutshell are:

1) you must maintain a handle to the Datasource as long as you are using 
objects from it (with some exceptions such as XXX).  If the Datsource is 
destroyed, developer pays for all damages.
2) Geometries returned by GetGeometryRef() become stale when its parent 
dies.
3)  FieldDefn must have their parent FeatureDefn alive.

I might have these wrong - the whole situation is rather confusing to me.

The only thing which is certainly a problem are bindings for gc 
languages.  Even if the developer maintains good habits, the gc might 
still collect the trash in the wrong order.  There are a couple of ways 
to mitigate this:  We could adopt a "no-fail" destructor strategy.  That 
is ensure that under no circumstances will destructors being called in 
the wrong order cause troubles.  Quite frankly I don't know how this can 
be done.   The other is to have Charlie implement his "backreference in 
script-lang" swig hook for Ruby.  His typemap is both ingenous and 
devious at the same time and hence has quite a bit of beauty.  My 
biggest object to it was it doesn't solve the problem for all 
languages.  But if we can sick out our chins and state in large 
commanding voices, "There are no problems in python," then we don't have 
a problem to solve.

>However, I leave it in your hands. 
>
>  
>
I appreciate the confidence.  My preferred solution at this time is to 
deny the problem in python and perl and php and lua and require the 
developer to follow the C api usage.  And have Charlie mix up his wicked 
potion of chicken bones and tea leaves and fix Ruby.

But I do defer to Your Honorable +/-1.

Kevin