Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Tamas Szekeres]

Umberto,

4.10 should be major enough to take such a changes.

Tamas


2006/8/17, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> Tamas,
>
> On 8/17/06, Frank Warmerdam <warmerdam at pobox.com> wrote:
> > Tamas Szekeres wrote:
> > > Hi All,
> > >
> > > According to the
> > > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1803
> > > and the agreement on the recent IRC meeting the following object
> > > members will be marked as immutable on the SWIG interface:
> > >
> > >
> > >  layerObj.metadata (hashTableObj)
> > >  classObj.label  (labelObj)
> > >  classObj.metadata  (hashTableObj)
> > >  classObj.layer  (layerObj)        already marked as immutable in
> > > mapscript.txt
> > >  fontSetObj.fonts  (hashTableObj)
> > >  imageObj.format  (outputFormatObj)
> > >  labelPathObj.path (lineObj)        missing documentation about
> > > labelPathObj in mapscript.txt should we expose at all?
> > >  legendObj.label  (labelObj)
> > >  legendObj.map  (mapObj)
> > >  mapObj.symbolset (symbolSetObj)
> > >  mapObj.fontset  (fontSetObj)
> > >  mapObj.labelcache  (labelCacheObj)
> > >  mapObj.reference  (referenceMapObj)
> > >  mapObj.scalebar  (scalebarObj)
> > >  mapObj.legend  (legendObj)
> > >  mapObj.querymap (queryMapObj)
> > >  mapObj.web  (webObj)
> > >  mapObj.configoptions  (hashTableObj)
> > >  webObj.map  (mapObj)
> > >  webObj.metadata  (hashTableObj)
> > >
> > > Generally there is no need to create these objects externally since
> > > they have been created internally.
> > > External creation of these members are unsafe, instead folks should
> > > work with the already created objects by reading the members mentioned
> > > above.
> > >
> > > If I get no objections till Aug 17 10:00 (Central European Time) i
> > > will change map.h and mapscript.txt accordingly so as to get it for
> > > 4.10.0-beta1.
> >
> > Tamas,
> >
> > Note, I thought we were just voting on making the metadata value on
> > the layerObj immutable, not all of these things.  The metadata fields
> > on the various objects is an actual hashTableObj (as opposed to a pointer
> > to a hashTableObj) so the default copy operator's shallow copy doesn't
> > do what we want.  I think items like "layer" on classObj, which is a
> > pointer, is a different case.
> >
>
> I agree with Frank.
> Furthermore I know of some people who reported issues using those
> methods in Java mapscript, so I suggest that we wait for a new major
> release before breaking backward compatibility.
>
> Umberto
>
> > I would say at the least make all the hashTableObj's immutable to
> > mapscript.  Consider doing this for other embedded structures like
> > mapObj.symbolset.  But hold off on changing the fields that are
> > pointers (like classObj.layer) till the matter is discussed further.
> >
> >
> > Best regards,
> > --
> > ---------------------------------------+--------------------------------------
> > I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> > light and sound - activate the windows | http://pobox.com/~warmerdam
> > and watch the world go round - Rush    | President OSGF, http://osgeo.org
> >
>