Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Tamas Szekeres]

Along with Frank's +1 on the IRC we have at least +3 so i have
committed the changes.
HISTORY.TXT contains the interface elements affected.

/me thinks it was a bit sweaty but was worth the trouble

Tamas


2006/8/17, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> +1 from me too. The nice thing it's a beta release so there's still time
> if we
> find we've overstepped a boundary. This is good discussion and I want
> to
> thank Tamas for the investigative work and solution (and Umberto for
> taking
> time from vacation - you're more generous than I!)...
>
> Steve
>
> >>> Daniel Morissette <dmorissette at MAPGEARS.COM> 8/17/2006 4:03:53 PM
> >>>
> After a bit more thinking and discussion on IRC, I am with Steve and
> also think that all the members that are listed in Steve's email can
> safely be made immutable since it would not make sense to attempt to
> overwrite them anyway. (That's also the way things are in PHP MapScript
>
> and that never stopped us from doing anything).
>
> With respect to imageObj.format, I think it should be made read-only or
>
> hidden since we get an imageObj from methods that create the actual
> image, and changing the outputFormatObj on the image after it's been
> created is just asking for trouble (not to mention the possible object
>
> referencing issues that Tamas is trying to address).
>
> I give my +1 to go ahead with this.
>
> Also please make sure you include a note listing the members that were
>
> made immutable in HISTORY.TXT.
>
> Daniel
>
> Steve Lime wrote:
> > 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/
> >>
> >
> >
>
>
> --
> Daniel Morissette
> http://www.mapgears.com/
>