Bug 1803, Upcoming breaking changes for 4.10.0-beta1
szekerest at GMAIL.COM
Thu Aug 17 07:32:47 EDT 2006
4.10 should be major enough to take such a changes.
2006/8/17, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> 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.
> > 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
More information about the mapserver-dev