On Fri, 22 Dec 2017 11:19:40 -0500 Cedric Bail <ced...@ddlm.me> said:
> > -------- 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.
of course bindings can expose and use it.
obj.del();
unlike c there may be another SCOPE reference at the top in the target language
so it's be equivalent to:
begin scope -> {
efl_ref(obj);
...
efl_del(obj);
...
efl_unref(obj);
} <- end scope
> 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.
it does always set parent to null... and that results in an unref... or it just
unrefs. either way a del results in an unref - always (unless intercepted for
special reasons like caching etc. but from the outside it should look like it
was an unref).
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
------------------------------------------------------------------------------
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
