> 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
