Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Tamas Szekeres]

Umberto,

>
> if you look closely at the macros in mapcopy.h you'll see that memory
> is correctly deallocated. There should be no need to deallocate the
> original structure as we only copy the members.
>
I'm still uncertain about the correctness of the proposed solution.
For example msCopyHashTable in msCopyWeb does not clear the previous
elements so the elements of the newly created web object and the
original will be merged. Another issue is when not all of the elements
are copied (eg layerinfo, items, iteminfo in msCopyLayer). That's why
i can see the freeXXX  - initXXX -  copyXX sequence when making such
things in the current implementation (freeWeb - initWeb - msCopyWeb in
this case). And must be noted that the resulting object might not
carry all of the behaviour of the original object. The copied layer
will be closed for example when using layerObj.clone.

>
> I think you mistake correctness for performance.
>

Not really. I can imagine that the proposed solution could be made
correctly and also the access violation problems are considered as a
secondary issue for me.
My main problem is (that I would like to impress with my previous
postings without any success)  that the interface incorrectly reflects
what happens behind the scenes and therefore the user may not get what
she expects. Allowing to set the web member may impress that the
mapObj.web member is implemented as a reference and the newly created
webObj will be the object pointed by this member. The user may not be
totally sure whether a cloning of the underlying web object happens
and might want to set the properties of the newly created web object
expecting that the members of the mapObj.web will also be changed for
example.

>
> All mapscripts had mapObj.setWeb until last week, I am only trying to
> make it work. Programs that did not work now will do.

Along with Steve i am not sure whether the folks will furiously
beating the door by reclaiming those members to be settable when they
have a simpler and safer solution to achieve the same result. Let's
wait for the user's feedback on it if any. I don't think if it was the
only backward incompatible change was made before in the history of
the SWIG mapscript interface. (Let us revert them all!  ;) )

> I don't think it
> breaks any backward compatibility, but please correct me if I'm wrong.
>

The SWIG C# binding uses the property notation when creating the
interface from the struct members. Users will access these members as
properties instead of using the corresponding getters/setters.

For example i was able to do the followings before:
mapObj map = new mapObj("mymap.map");
webObj web = new webObj();
map.web = web;

With the proposed solution the latter should be replaced with:
map.setWeb(web);


Tamas