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