Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Steve Lime]

It would be nice to get this settled though for this release. I can see
where we don't want people
overwriting elements that are already in place. Immutable just means the
object itself can't be
overwritten not that it's properties cannot be modified, correct?

Why would we even want constructors for things like a label without
methods to safely add
them to a parent object? With classes and layers we have those methods.

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).

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-259-5473
>>> Frank Warmerdam <warmerdam at POBOX.COM> 08/16/06 7:47 PM >>>
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 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