Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?

[Patrick Ohly <patrick ohly gmx de>]

On Fri, 2014-05-16 at 19:28 +0200, Milan Crha wrote:
> The main problem is that the API returns pointers which are part of the
> structure that you ask the value of it - like when you ask for a
> subcomponent of an icalcomponent. If it exists, you get a child of the
> parent component. This makes a disaster due to the unpredictable memory
> management in python or javascript (introspection-using languages in
> general?). The libecal uses this libical behaviour too. As an example,
> if you ask for an alarm of an ECalComponent, then you receive a new
> structure which holds a libical structure, which is part of the
> ECalComponent (icalcomponent of it). Any changes done through this
> structure are immediately propagated into the parent's ECalComponent,
> aka there is no "save" involved. If you free ECalComponent before the
> alarm structure, then the free of the alarm structure causes a crash. As
> you cannot influence the memory-free time in python... and even if it
> would be possible, then we cannot expect from the introspection
> interface users (developers) to tweak their code in a way they are not
> used to (like making some memory/variable management on their own).

Aren't you going to run into the same problem with a GObject-based
proxies for these libical objects? The proxies are reference-counted,
the libical objects are not, so they may go away before their proxies
do. This would leave the proxy with a dangling pointer or (if it somehow
tracks the lifetime of the owner of the object) in a state where it is
unusable.

Bye, Patrick