[Gdal-dev] GetGeometryRef in scripts

[Ari Jolma]

Let me theoretize a bit on this subject, because it confuses me, when 
you (seem) to be talking about specific cases. I'd like to see a very 
short list of rules, and then think what should happen in each case.

First, in my previous post, forget about Perl be able to detect, but 
remember the principles, that we ought to be able to do in-place 
manipulation of objects (for speed) but also be able to take an object 
from its container and have it although the container goes away.

An object must know about its' container, so that when the object is 
really destroyed, the destructor needs to check the container, and 
destroy also it, if it isn't referenced by anybody else.

When a container is really destroyed, all the objects that it contains, 
are also destroyed. If an object, which is thus being destroyed, is 
referenced by somebody, then it must clone itself and continue living.

Am I missing something? Isn't this all about objects, references to 
objects and their containers? And the about when an object or container 
is really destroyed. There aren't that many possible cases and it 
shouldn't be impossible to look at each case and decide what happens. 
And, is there a difference between an object and a container? A 
container is just an object which owns another object?

If you give an object to a container, it could always be just by 
reference. If the original owning variable goes out of scope, the object 
reference in the container must clone the real object and become also a 
real. We can give it explicitly by value to avoid cloning, though.

I don't see it impossible to implement this in the thin C/C++ layer 
between scripts and GDAL. As far as I understand the only important 
missing piece is the link from an object to its container. That's also a 
rule: an object can be (owned) in only one container.

The variables in the script are always just references to the actual 
objects under the hood. The engine below must take care that the correct 
objects exist. It is difficult because we're just responding to messages 
(like in GUI programming) and do not have complete control.

Ah, maybe this is enough for now ;)

Ari


Kevin Ruland kirjoitti:

>
>> 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
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev



-- 
Prof. Ari Jolma
Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma