Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Umberto Nicoletti]

OK, let's wait and see what happens.

Umberto

On 8/23/06, Tamas Szekeres <szekerest at gmail.com> wrote:
> 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
>