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 _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
