On Fri, 6 Sep 2013 19:16:38 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> On Fri, Sep 6, 2013 at 1:30 PM, Iván Briano <[email protected]> wrote: > > On Fri, Sep 6, 2013 at 9:28 AM, Tom Hacohen <[email protected]> wrote: > >> On 05/09/13 17:42, Gustavo Sverzut Barbieri wrote: > >>> Hi all, > >>> > >>> Why eo_del() doesn't flag the object as deleted and issue an event > >>> callback? > >> > >> Because the object might still be referenced. It could be done though, > >> we haven't decided one way or the other, this might be a reasonable > >> approach as well. I'll think about it, as this approach also has its > >> merits. This however does not mean that the object will be completely > >> deleted. We'll may call the destructors, and even block eo_do, but we > >> will not free the objects. > > Fully agree we shouldn't free the memory... but as Iván says in his > mail we must notify people that they must release their reference for > good. i agree - there should be a del callback so "listeners" who have a ref can know and so whatever it is they need to do. a del callback indicates an owner really wants this object gone, but references may be keeping it around. but as long as its reff'd methods need to work as other referrers may need to steal data/state out of the object via methods. > > >>> As it is I feel it is pretty useless, you do the "del", it becomes > >>> unparented and unrefs, but other than that no users will know they > >>> should release their references... and you can keep calling object > >>> methods without problems. > >> > >> They should know that in eo land, you have references, and you need to > >> account for them. See what I wrote above. > >> > > > > Yes, that's the point. If everyone has a reference to the Evolving > > Object and they > > drop it, then no one has a reference, the object is deleted and we all > > go on our merry ways. > > But if I am the irrevocable owner of the object and I want to delete > > it because it offended my pet, > > I won't care who's holding a reference to it and just call eo_del(), > > expecting that its acquaintances > > will hear about the fatidic news and drop their references as they see fit. > > exactly... and this was the case with our previous object: > Evas_Object! We had EVAS_CALLBACK_DEL to be called right when you > delete... you also had a flag to notify it was deleted... you also > ignored the operations on deleted objects. You also did NOT free the > memory. > > BTW we had 2 events, one added by me that was EVAS_CALLBACK_FREE to be > used in bindings and other cases where you'd want to know when the > object really goes away. I don't recall the details of this 2-stage > death, but certainly need it :-) i think in eo - as a general thing, methods need to keep working because in a general sense they just need to. but yes - a way to query if a obj is in a deleted state would be very useful. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
