RFC-24 Mapscript memory management: call for comments

[Frank Warmerdam]

Tamas Szekeres wrote:
> Umberto,
> 
> My personal attitude to this RFC is slightly ambivalent. On one hand I
> appreciate your efforts to discover the similarities and the
> differences between the various languages
> regarding to a particular problem and it's also appealing that one of
> our ancient problem had been tempting the mapscript users for a long
> ago was included in the proposal.
> But on the other hand one of the problems enumerated is not considered
> to be a problem (by me), however a large amount of code should be
> altered so as to "fight against it", and even I doubt that this
> solution is working correctly as it stands.

Umberto,

I'm concerned about the substantial disruption to backwards compatibility
that seems to be implicit in this proposal.  I would appreciate it if the
RFC could have a section discussing the compatibility problems that will
be caused by the proposed changes.

On the one hand, I appreciate the effort you have put into this RFC, and
your willingness to take on a thorny problem.   On the other hand, my
understanding of mapscript use and the different language bindings is
sufficiently weak that I don't really see the problem(s) being solved.

/me re-reads, and really tries to grok the RFC...

2.1 Object equality/identity

OK, I agree with Tamas on this. I think it is unfortunate that the
insertLayer() is really just copying the original layer rather than
literally inserting that instance, but I think this is just something
we can document and it is easily worked around.  Generally speaking
I think we should be discouraging creating "free standing" layerObj's.

2.2 Early garbage collection

Tamas writes:
 > That's really an issue, and a reference to the real memory owner
 > object should be kept by the child to avoid the crash.

My opinion is different.  The map is the main object, and I think it
is up to applications to keep a handle to the map as long as they want
to do stuff, and once the map is released (dereferenced) the
application  should not use any part of the map.

2.3 Dynamically populated layers, classes, etc

I'm afraid I'm not clear on what the issue is here.  I tried digging
through the bug reports, but this did not turn out to be an easy way
to understand the problem.  I'd encourage you to explain the problem,
and perhaps refer to the bug reports as supporting information.

Tamas's suggestion seems to make sense to me, but only in a rough
sort of way since I was unable know the details.  Certainly I
can understand that we need a way in a constructor to distinguish
between returning a reference to a pre-existing object as opposed
to a brand new one "owned" by the reference.

I'm afraid I got quite lost in the proposed implementation.  It seems
the changes are quite dramatic and I too worry about whether it would
ever work properly and whether the changes will be so dramatic that
they break all existing mapscript applications.

I wish I understood swig better.  The mapscript bindings, and the
"next generation" GDAL/OGR bindings seem so complicated that I am
quite lost.  This no doubt means I'm a bit dumb, but I'm sure I'm
not the only one getting overwhelmed by it.  If things get so
complicated that only very few developers can grok them then
getting maintenance done becomes increasingly problematic.

I know that Howard is at least in a general sense enthusiastic
about RFC 24, but I certainly feel uncertain about it so far.
Perhaps some additional work can be done to clarify the RFC (ie.
a compatibility section), and to try and iron things out with Tamas
who clearly has a much better understanding than I do.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org