> -------- 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
