SWIG mapscript critical problems!!!

Umberto Nicoletti umberto.nicoletti at GMAIL.COM
Thu Jun 22 09:57:34 EDT 2006


On 6/22/06, Tamas Szekeres <szekerest at gmail.com> wrote:
> Umberto,
>
> 2006/6/22, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> >
> > This solution implies an API change which I don't favour. I like
> > better the solution you have already implemented in csmodule.i but it
> > needs to be extended to other languages and to other functions like
> > insertClass, setMetadata, etc.
> > Btw have you seen how the ruby people are doing it?
> > http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn57
> >
>
> 1. In this case SWIGTYPE DISOWN is not usable since the behaviour
> depend on the parameter. If null parameter is given for the
> constructor disowning the internal memory will result in a memory
> leak.
> 2. I wonder is DISOWN works for C# by looking a the documentations and
> the swig source tree.
>

I was referring to that smart object tracking which would ensure that
even object identity works,but that's not the point here. It seems to
have itw own set of problems though:

http://comments.gmane.org/gmane.comp.programming.swig/7813

> > > For example layerObj.map is handled internally and is solely for
> > > getting the reference of the parent object.
> >
> > In Java you can't set the map reference, only get it.
> >
>
> Ok, i was thinking of legendObj.map for example, apologies.
>
> >
> > Because not all mapscript objects are properly set up: for instance
> > webObj until recently did not have a constructor which invoked initWeb
> > so the metadata had to be set from Java. This can be solved of course,
> > but it would break backwards compatibility (API change).
> >
>
> I would discourage to maintain unintentionally exposed interface
> elements just for retaining the backward compatibility. Users should
> not create objects from scratch and add them to a parent object is it
> has already been constructed during the parent object creation.
>

I agree. We could make those functions deprecated and then remove them
in a release or two.
We need to document this on the web site (you see I'm sticking with my
ideas ;-))

Best regards,
Umberto

>
> Regards,
>
> Tamas
>



More information about the mapserver-dev mailing list