Bug 1803, Upcoming breaking changes for 4.10.0-beta1

[Tamas Szekeres]

Frank,

I can see a slight confusion about the objective of these changes so i
am trying to explain it once again.
1. Primairly i would like to remove the harmful interface elements
causing potential problems.
2. In addition i would like to make the interface more clear and
removing the elements not reflecting the internals properly.

Let me explain these issues in more detail:

1. a, Objects with struct members
When setting object members SWIG will make a shallow copy of the
member (might be considered as a raw memcopy in effect).
If this member is a struct the subsequent objects will not be
duplicated so these objects will be owned by 2 SWIG elements and will
be freed twice.

For example setting layerObj.metadata with a newly created
hashTableObj  "struct hashObj **items" is not cloned so when
destroying the layer freeLayer will call msFreeHashItems unmercifully.
The following members are candidates to cause this issue (objects with
struct members):

  layerObj.metadata (hashTableObj)
  classObj.label  (labelObj)
  classObj.metadata  (hashTableObj)
  fontSetObj.fonts  (hashTableObj)
  legendObj.label  (labelObj)
  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.metadata  (hashTableObj)
  labelPathObj.path (lineObj)	  (will be completely hidden according
to Steve's suggestions)

After all, some of the objects might not be externally constructable
but i was not addressing this issue since constructing those objects
is not harmful.

1. b, Object with object reference members
If the member is a pointer to a structure only the pointer will be
copied and the object might be owned by 2 SWIG elements as well. When
the object has a member withpointer reference to another object
considering it excusively owns the referce may also result in
problems.
imageObj.format is the case since the refcount is not incremented on
the format when setting this member.


2. The members mentioned previously (1.a) brings in a confusion for
the users since the members are to be created internally not to be
created by the user. The user should only get the object reference and
play with it freely.
There is another confusion about the objects having references to the
parent objects. No one should think that by setting this member to
another object the object will belong to the another object after it.
So there's no use to set this element at all.
The interface should be unique at this point so all references (not
only layerObj.map) should be immutable. And the interface description
is also incoherent since classObj.layer is noted as immutable but if
is writable in effect.
The following members are denoting this category:

  classObj.layer
  legendObj.map
  webObj.map
  referenceMapObj.map  (forgot to mention in the previous post)


I would have a guilty conscience by making partial changes of this
problem and leaving open issues in.

2006/8/17, Frank Warmerdam <warmerdam at pobox.com>:

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

May i understand this as 1. a, should be handled?

I am preparing the changes according to 1.a and waiting for another
confirmation about 1.b and 2. Should we delay this issue to beta2 or
later?

Regards,

Tamas