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.
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
