On Thu, 21 Dec 2017 13:29:05 -0500 Cedric Bail <ced...@ddlm.me> said:
> Hi,
>
> > -------- Original Message --------
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: December 21, 2017 9:02 AM
> > UTC Time: December 21, 2017 5:02 PM
> > From: a...@andywilliams.me
> > To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
> >
> > P.S. if the loss of temporary handles with efl_add is not met with
> > efl_added it would be possible to add a new macro along the lines of:
> >
> > efl_add_scope(klass, parent) { ... statements ... } whereby the scope of
> > the variable is valid only within that block.
>
> This is an interesting idea that give an explicit lifecycle to the newly
> created reference and when you safely own it.
>
> > On Thu, 21 Dec 2017 at 13:15 Andrew Williams a...@andywilliams.me wrote:
> >
> >> Hi,
> >> This is now well documented (
> >> https://www.enlightenment.org/develop/tutorials/c/eo-refcount.md) but the
> >> more I use efl_add the more I feel it is confusing especially to new
> >> developers.
> >> In the current model (if I understand it correctly)
> >>
> >> - child = efl_add(klass, parent) means the child must NOT be unfeferenced
> >> - child = efl_add(klass, NULL) means the child should be unreferenced
> >> - child = efl_add_ref(klass, parent) means the child must be unreferenced
> >> - child = efl_add_ref(klass, NULL) somehow means that the child should be
> >> unreferenced twice
> >>
> >> In my opinion 1) and 4) are peculiar and so I provide a proposal to fix
> >> this:
> >> We could change efl_add to return void. It never retains a reference. If
> >> the parent is NULL then it should be automatically unref before returning.
> >> Then efl_add_ref would be changed to mirror this and always retain exactly
> >> 1 reference - so if parent is NULL there is no double count returned.
> >> Using this model if an Eo * is returned then I know I have a reference and
> >> must later unref.
> >> Any need for using the pointer in an efl_add (which is no longer returned)
> >> would still be supported through efl_added within the constructor.
> >> What do people think about this? I put the suggestion forward to improve
> >> the symettry with add and unref which is currently confusing. If my
> >> assumptions above are incorrect please let me know!
>
> We have been trying to fix the semantic problem of efl_add since pretty much
> it was created. This proposal seems to build on top of efl_add_ref that was
> added to fix the problem created for binding. I do like this proposal at it
> start fixing the problem of inconsistency when creating an object. An
> additional fix is that we would not need any more an efl_del as efl_unref
> will be the only thing needed (efl_del is a weird thing that does unset the
> parent and unref somehow, but can't also be used safely by binding). This
> would make for a cleaner semantic and less surprise in refcounting.
i disagree that unref is all that is needed. here is a case we hit in legacy
api:
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.
--
------------- 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
