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... 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 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) 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. The more I look at it the more I think we have too much UI related thinking in our object lifecycle. Andy On Wed, 3 Jan 2018 at 05:41 Cedric Bail <ced...@ddlm.me> wrote: > > The whole efl_del argument just exist because it is kinda poorly > > named. IMO, del means: get this object to an "empty" state. > > Just like close to files and hide and unparent to UI objects. efl_del > > should not steal references under people who owns it, the object > > would get deleted at a later time when everybody using the object > > stops doing so, we could even return errors from efl_del'eted > > objects for methods that do not make sense anymore, causing > > most actions to, possibly, halt earlier rather than later. > > So, if efl_del does not still a references under people who owns it, how > do we fix it ? Should it still magically reset its parent to NULL when > there is one and just efl_unref in the other case ? Should it be symetric > to efl_add_ref and always reset the parent to NULL along with unref ? Or > should it do none of this at all and you have to manually do the parent set > and the unref ? > > Trying to figure out what behavior would make it work for binding, I would > guess it would be best to just make it symetric to efl_add_ref. This will > give a predictable outcome I think, but I am not sure it is enough. What do > you think ? > > > IMO, the whole problem with efl_add/efl_add_ref is that > > "parents" are treated specially, which they should not. parent_set > > should increment efl_ref and parent_unset should decrement it. > > Agreed and surprised it is not the case. > > > For C, OTH, where we do expect some "automatism" on resource > > handling, efl_unref'ing may be too much of a hassle when a > > parent is already going to handle the lifetime of the object. So, > > it would make sense, IMO, for efl_add_scope. It could even be > > that efl_add_scope is named efl_add, no problem, as long as > > there's a efl_add that keeps this semantics for binding > > development. Which also means that parent_set/unset must > > be fixed. > > I think that once efl_del behavior is clearly defined, the existence of an > efl_add_scope/efl_add will also be clearer to everyone. > > > Also, @own tags must not relate to parent_set, because that > > has no useful information for tags or users, if needed we can > > add a @reparent tag, but that's not really special information > > such as real owernship information. > > I am still wondering what the @own really mean. Does that mean that the > object own at least one reference of it ? But in that case, doesn't that > mean that the user need to always ref it, if it plans to keep it around. > > As for @reparent, I am not sure we have case yet where we return an object > that can not be reparented, do we have such a case ? > > 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
