Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Umberto Nicoletti]

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

As I said earlier *I am on holiday* and I will fix this asap as I have
always done. Also my fix will allow (I hope) the user to do what he
needs to do, not deny it.

And btw the proof of the metadat exception still does not cover all of
the other proposed changes, only the one that I also approved and
suggested that it be delayed until version 5.

I'll check my email again tomorrow, I have to go now.

Umberto

> 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/
> > >
> >
>