Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Umberto Nicoletti]

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
>