On Wed, 03 Jan 2018 00:41:30 -0500 Cedric Bail <[email protected]> said:
> > 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 ? my take on efl_del is this: 1. is is allowed to do things like "hide objects", "close fd's" etc. like felipe said, BUt it will not unparent UNLESS this is the LAST ref, then it unparents (which is equivalent to an unref in addition to removal from parent as any removal from the parent removes a ref). > > 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 ? i think we will have the case for: 1. objects must have a parent that is in the main loop tree (as they are bound to the main loop and main loop only). 2. objects that must have NO parent (and no references to objects outside of their child tree) (if we ever support transfer of objects from thread to thread). > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
