Hi, I would avoid the name efl_release if it is not to do with object lifecycle as that is the word ObjectiveC uses in their retain/release pair for memory management.
Just a thought if we are trying to attract devs from elsewhere. Andy On Thu, 4 Jan 2018 at 00:04 Cedric Bail <ced...@ddlm.me> wrote: > > -------- Original Message -------- > > Subject: Re: [E-devel] efl_add causing confusion > > Local Time: January 3, 2018 1:43 AM > > UTC Time: January 3, 2018 9:43 AM > > From: a...@andywilliams.me > > To: Enlightenment developer list < > enlightenment-devel@lists.sourceforge.net> > > > > Hi Cedric, > > > > I think I agree, if we can tidy the definitions then everything should > get > > clearer. > > > > efl_add_ref being needed for bindings implies that our definition of > > efl_add was not clean enough in the first place. > > If efl_del is "hide and unparent" then maybe what we really need is > > efl_gfx_hide and efl_parent_unset - but I don't see why we need to > unparent > > anyhow... > > After some discussion with Felipe we came to the conclusion that efl_del > is not properly design and the core problem is indeed that it does to many > things. Our idea is to split it in two part. efl_release that will have > different meaning on object, could close a socket if it an network object > for example or hide and remove from scenegraph if it is a canvas object. > This will not affect the object lifecycle. It will make it emit a new event > once it is released (This would be a first step, but later on we would > likely want to block some function from working when an object is released > and the ability to unrelease an object). > > The second function would be what efl_del kind of does, but moved to an > inline function that call efl_release. This way binding can use release (it > doesn't randomly mess with the object life cycle) and provide their own > logic for del. Now in C, it is still not obvious what efl_del should do in > term of unparenting and unref. Right now, it does a wonderful if there is a > parent, then unset the parent, if there is no parent, then just unref. But > in the following example : > > obj = efl_add(CLASS, NULL); > efl_parent_set(obj, some_parent); > efl_del(obj); > > obj will still have one reference, but no parent left, while in the > example below : > > obj = efl_add(CLASS, some_parent); > efl_del(obj); > > The object will have been properly destroyed. This kind of problem happen > easily in our API when we actually return a new Eo object. Depending on how > we create it, its reference count might change. My personal take is that > efl_del should not do anything on the parent. If we give an object to be > managed by the parent, del should not be the one touching it. The parent > should. So I would argue that efl_del should just be efl_release + > efl_unref. > > > If we are delegating to a parent to manage the lifecycle of the object > then > > we should step away from the reference and forget it - that is the most > > "convenient" behaviour I guess. > > > > if: > > efl_add always returned an owned reference and took no parent > > efl_add_child never returned an owned reference and required a parent > > This seems to match the change we think are necessary to efl_del. > > > then: > > efl_add_ref* would no longer be required right? (if the binding requires > a > > ref after efl_add_child we have efl_ref that it could wrap up) > > We could still provide an efl_add_ref helper in C too, but otherwise yes > to your point. > > > efl_del would take a reference and dec (probably not needed as we have > > efl_unref?) > > efl_del_child seems unlikely to be needed as all that is left is hiding > > which is a graphics call, not an eo lifecycle one. > > I am not a fan of the idea of an efl_del_child, but as it would be an > inline helper, it can be done later if we feel it is useful. > > This proposal would work for binding. Right now, they rely on efl_unref > and can't call efl_del due to the unpredictable lifecycle that result of > it, cleaning that, clean also the other side of the confusion by making > efl_add more rigorous in its behavior. > > 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 > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ 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
