> -------- Original Message -------- > Subject: Re: [E-devel] efl_add causing confusion > Local Time: December 21, 2017 7:18 PM > UTC Time: December 22, 2017 3:18 AM > From: ras...@rasterman.com > To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net> > Cedric Bail <ced...@ddlm.me>
<snip> >> you have an object and you do evas_object_del(). you can keep the object >> alive >> with more refs, but del SHOULD hide the object. refs should not affect >> VISIBILITY of the object, thus a del is different to an unref. >> >> del == "remove a reference from this object and otherwise act as if this >> object >> should now be deleted". >> >> unref == "just remove my reference to this object. this MAY result in a del >> behavior at some point, but i'm simply releasing a reference and not actually >> explicitly ending the lifetime of this object". >> >> semantically they are quite different things. You missed my point, bindings can not use del due to the semantic of it as it might unparent or might remove a reference, they can't control its behavior. Sure it is nice to have a del that you can override in a class as oposed to unref, but if just C can use it, there is no point in it being in a Eo object. Now if we want to continue to provide efl_del facility a proposal solution need to be tested with binding. I would expect that if it did always set the parent to NULL and always unref, it would be more usable by binding, but it still require testing that and all the change proposed by Andrew. 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
