Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Tamas Szekeres]

Steve,

I think Umberto thinks of this issue is the same as were noted in
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1743
that was fixed for C# but still open for the other bindings.

Funny enough he gets bug report on it but still miscredits the evidence.
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1841

These issues are quite a simple ones.
Now then am thinking the working on threading issues is a mission
impossible and takes much more potency that i does not have.  :(

Tamas


2006/8/17, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> Umberto: How do you add classes and layers at runtime? In the context of
> a layer or a map
> correct? I don't believe that what Tamas is proposing would change that
> capability at all.
>
> If you look at the list:
>
> classObj.layer
> webObj.map
> legendObj.map
> layerObj.map
>
> are back references and you don't want folks monkeying around with
> them.
>
> classObj.label
> legendObj.label
> mapObj.scalebar
> mapObj.legend
> mapObj.querymap
> mapObj.web
> mapObj.symbolset
> mapObj.labelcache
> mapObj.reference
>
> Already exist in their parent objects so there is no need to create new
> ones in place of the
> existing ones. Users should get the reference to the existing structure
> and modify it in place.
> I'm not sure that given the potential problems that it even makes sense
> to have constructors
> for these. I assume this is the contentious spot...
>
> (If there is a glaring need to have, for example, an unattached
> labelObj laying around then
> couldn't a populateFrom capability be developed for a labelObj, or
> perhaps setLabel() for a
> classObj?)
>
> classObj.metadata
> fontSetObj.fonts
> mapObj.configoptions
> webObj.metadata
>
> Are hash tables and Sean created a nice interface for them to use.
> Modifying directly shouldn't
> be allowed. I think this is what was ok'd yesterday.
>
> Note sure about  imageObj.format...
>
> I guess I don't see the big deal with this change. My 2 cents.
>
> Steve
>
> >>> Umberto Nicoletti <umberto.nicoletti at GMAIL.COM> 8/17/2006 8:25 AM
> >>>
> On 8/17/06, Daniel Morissette <dmorissette at mapgears.com> wrote:
> > Tamas Szekeres wrote:
> > >
> > >> I think you can safely hide the labelPathObj, that should not be
> > >> exposed. I think the others
> > >> should be immutable too (assuming I understand the problem
> correctly),
> > >> the question is how
> > >> many scripts will the change break and should backward
> compatability
> > >> breakage be limited
> > >> to major releases (e.g. 5.0).
> > >>
> > >
> > > Those scripts are *erroneous* !  It would be desirable to force
> the
> > > users to put them into a good shape as soon as possible.
> > >
> > >
> >
> > It seems that I should take position as release manager but
> > unfortunately I do not know or use SWIG MapScript much so I have to
> rely
> > on those who know to make an opinion on whether the current stuff is
> > dangerous enough to warrant breaking a few scripts with 4.10.
> >
> > Based on the understanding I have of the problem from reading this
> > thread and previous discussions, it seems to me that if those
> scripts
> > are doing something that is just waiting to bomb then changing SWIG
> > MapScript in v4.10 to make those object references immutable is not
> a
> > backwards compatibility issue, it is a bugfix and a service we are
> > making to those users by forcing them to fix their scripts... and in
> the
> > end their apps will just be more robust.
> >
>
> Daniel,
> IMO  we are talking about fixing pieces of code we are not even sure
> they are broken. For instance I have some Java mapscript tests (and an
> application) running just fine that add layers and classes at run time
> and that's why I am so reluctant in approving this proposal. Only once
> we get a test case that reproduces this errors reliably then we can go
> and change the code.
>
> Unfortunately I couldn't join the IRC meeting because I am on vacation
> otherwise I'd have spoken  earlier (I am writing this on the road).
>
> Regards,
> Umberto
>
> > The real question that I would throw at the SWIG MapScript experts
> is:
> > "Is the practice of overwriting those object references really
> dangerous
> > or not?"
> >
> > If the answer is yes then I think that solves the question and we
> need
> > to apply the fix and force users to fix their scripts.
> >
> > If there are object references that can safely be overwritten (such
> as
> > colorObj) then my opinion is that we should not touch them in 4.10.
> >
> > Daniel
> > --
> > Daniel Morissette
> > http://www.mapgears.com/
> >
>