Bug 1803, Upcoming breaking changes for 4.10.0-beta1
Sean Gillies
sgillies at FRII.COM
Wed Aug 16 19:56:35 EDT 2006
Hi Tamas,
Yes, I agree it should be discouraged, but users have become
accustomed to this improper usage. Perl, in particular, lets you get
away with it. I'm in favor of the changes, just want to encourage you
to alert users early.
Sean
On Aug 16, 2006, at 5:03 PM, Tamas Szekeres wrote:
> Hi Sean,
>
> Nice to hear from you again!
>
> Setting colorObj is considered as safe since the raw copy of the
> struct will copy all of the elements by value. The problematic members
> are objects having subsequent object references.
>
> Theoretically
> myclass.label = new labelObj();
> should be completely discouraged since the label member has already
> been created.
> One should get the label reference at any time, and play with it as
> he want.
>
> Best Regards,
>
> Tamas
>
>
>
> 2006/8/17, Sean Gillies <sgillies at frii.com>:
>> On Aug 16, 2006, at 3:46 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.
>>>
>>> Regards,
>>>
>>> Tamas
>>
>> Tamas,
>>
>> Don't forget all the colorObjs. Sooner you get word of this to the
>> user community the better. Despite my warnings and heckling, code
>> like this
>>
>> $class->{label} = new mapscript::labelObj;
>>
>> is very common in user programs.
>>
>> ---
>> Sean Gillies
>> http://zcologia.com
>>
---
Sean Gillies
http://zcologia.com
More information about the mapserver-dev
mailing list