On Fri, 22 Dec 2017 09:47:34 +0000 Andrew Williams <a...@andywilliams.me> said:
> Hi,
>
> Surely hide and unref are separate? Why are we trying to do both with a
> single call to _del? If we wish to continue supporting "hide and unref" in
> a single call then we can - but as a convenience. It could be documented as
> such: "del will remove your reference to the object and, if the object is
> visible, hide it. Any other references will remain valid but will no longer
> visibly affect the object" nice and clear.
that was my point. del is different to unref. it may also do these other things
like unparent, hide, etc. etc.
> But I think cedric is still correct - unref is all that is "needed" - any
> user could _hide && _unref if they wanted - it would then be exactly the
> same as the _del semantic you describe.
>
> If we have to put a big OR in a simple method documentation then we are
> setting up confusion.
i think it's pretty simple - use ref and unref for REFERENCES, use add and del
for begnning and end of life. actual end of life may be delayed due to
references still being there.
> Andy
>
> On Fri, 22 Dec 2017 at 03:26 Carsten Haitzler <ras...@rasterman.com> wrote:
>
> > 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
> >
> --
> http://andywilliams.me
> http://ajwillia.ms
> ------------------------------------------------------------------------------
> 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
>
--
------------- 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
