> -------- Original Message -------- > Subject: Re: [E-devel] efl_add causing confusion > Local Time: January 8, 2018 1:15 AM > UTC Time: January 8, 2018 9:15 AM > From: j...@videolan.org > To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
<snip> > - Those numbers differ from the values given in the below email. > While I understand where this "maybe 1 or 2% of all objects [are created > without a parent]" comes from, it's not based on facts. > @noparent makes sense. A NULL check in efl_add would then help. > A different API then wouldn't hurt either IMHO (maybe efl_new? > efl_add_single? efl_create? or whatever -- efl_add then can NOT be called > with NULL). I am not sure of the semantic you expect here. Could you clarify ? > - The argumentation in this email chain again leads nowhere. The original > confusion remains mostly unaddressed. > Felipe mentioned that ownership and references are mixed. So the proposal > for efl_release (or detach, close, invalidate, ...) makes sense to me. > In fact we have issues sometimes with efl_del as inside a destructor we > already lost our parent (thus all efl_provider_find and related calls will > fail). > Also, quite a few times I've also been looking for a "deleted" event that > would happen after destruction, and not before. > I had to introduce a very ugly API very badly called "allow_parent_unref" > in efl.object because some objects need a parent but they should be > unref'ed by someone else (efl_part objects but not only). > > So, I think it would make sense to investigate efl_terminate, and > evas_object_del would just call efl_terminate, hiding the object or > starting destruction, then let the parent (either evas or another canvas > object) do the final unref/unparent and destroying everything that's left. I like this direction. It might even allow a way to not have the double step destruction we have today. Also it allow to solve the problem we have of referencing parent during destruction and weird refcounting for parenting. If we enforce that path, then during destructor it must be expected that the parent is NULL. When setting the parent to NULL, it will trigger an invalidate of the object (If the object is not invalidated already). This means that efl_del get simplified to just parent set to NULL followed by unref. Making it a direct symetric operation to efl_add_ref. > Anyway I think experiments only can tell us what's best. I see 3 items: > > - @noparent tag > - efl_new (= efl_add without a parent -- requires @noparent if we want > strong NULL check) > - efl_invalidate / efl_terminate (I prefer efl_close :P) I am now prefering efl_invalidate as efl_terminate is actually used by our lifecycle function and efl_close remind me of file. Cedric ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
