On Tue, Jan 9, 2018 at 7:30 AM, Cedric Bail <ced...@ddlm.me> wrote: > > -------- 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-de...@lists.sou > rceforge.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 ? >
Ah sorry it wasn't clear: #define efl_add(CLASS, parent, ...) #define efl_new(CLASS, ...) efl_add checks that parent != NULL and have EINA_ARG_NONNULL efl_new simply cannot pass a parent (unless of course you call efl_parent_set(efl_added)) the internal code can be the same (the null check being added in eo.c, if we want it -- it relies on @noparent) > > - 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. Do you mean evas object manual free? evas_object_del -> efl_invalidate (hides and calls existing destructor?) manual_free -> unref and final cleanup? > Also it allow to solve the problem we have of referencing parent during > destruction and weird refcounting for parenting. > Referencing the parent? You mean using pd->parent or something like that? Parent is NULL inside efl_destructor... > > 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. > Parent is already NULL inside destructor. Which I think can in fact be problematic sometimes (since efl_provider_find fails). From your sentence it would seem that the object has two refs? (parent ref + user ref) I'm not thinking of adding a ref to the object. IMO efl_add_ref is only for bindings, the ref dies after the scope ends (in C++ anyway). This isn't a fully formed idea yet (in my mind at least) > 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. Sure. -- Jean-Philippe André ------------------------------------------------------------------------------ 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
