On 07/11/2013 15:13, Carsten Haitzler (The Rasterman) wrote:
On Thu, 07 Nov 2013 13:00:59 +0100 Guillaume Friloux <guillaume.fril...@asp64.com> said:I am clearly speaking about breaking how it works. As far as i know, you always have to free yourself what you directly create (you dont bother about internal stuff). The only exception i know on EFLs (i only use the lower level libs) is Ecore_Con_Server.ecore_exe handles work the same. :)This is an object that you have to handle yourself (allocate and free) except in the case of a system error or dns error. My question wasnt about how it works, but is it possible to change this one day or not ? To me its an exception to everything done, maybe someone can prove me wrong.not quite a single exception. ecore_ipc too does this. and ecore_exe. the problem is that by changing this - we break existing code. and we are trying not to do that. i think this is something we put down for efl2.0 with all the eo stuff and then all objects behave and have the SAME lifetimes that work in the SAME way... :) for this.. ecore_con should use eo... (and ecore_ipc... and ecore_exe etc.)... i am more than happy with the idea that we start to fix the internals of things like these and use eo - but keep current behavior... and then for efl 2... you get exactly what you want. :)
Ok, efl2.0 then, thats all i was asking =)
<<attachment: guillaume_friloux.vcf>>
------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
