On Wed, 03 Jan 2018 19:03:39 -0500 Cedric Bail <ced...@ddlm.me> said:
> > -------- Original Message --------
> > Subject: Re: [E-devel] efl_add causing confusion
> > Local Time: January 3, 2018 1:43 AM
> > UTC Time: January 3, 2018 9:43 AM
> > From: a...@andywilliams.me
> > To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
> >
> > Hi Cedric,
> >
> > I think I agree, if we can tidy the definitions then everything should get
> > clearer.
> >
> > efl_add_ref being needed for bindings implies that our definition of
> > efl_add was not clean enough in the first place.
> > If efl_del is "hide and unparent" then maybe what we really need is
> > efl_gfx_hide and efl_parent_unset - but I don't see why we need to unparent
> > anyhow...
>
> After some discussion with Felipe we came to the conclusion that efl_del is
> not properly design and the core problem is indeed that it does to many
> things. Our idea is to split it in two part. efl_release that will have
> different meaning on object, could close a socket if it an network object for
> example or hide and remove from scenegraph if it is a canvas object. This
> will not affect the object lifecycle. It will make it emit a new event once
> it is released (This would be a first step, but later on we would likely want
> to block some function from working when an object is released and the
> ability to unrelease an object).
>
> The second function would be what efl_del kind of does, but moved to an
> inline function that call efl_release. This way binding can use release (it
> doesn't randomly mess with the object life cycle) and provide their own logic
> for del. Now in C, it is still not obvious what efl_del should do in term of
> unparenting and unref. Right now, it does a wonderful if there is a parent,
> then unset the parent, if there is no parent, then just unref. But in the
> following example :
>
> obj = efl_add(CLASS, NULL);
> efl_parent_set(obj, some_parent);
> efl_del(obj);
>
> obj will still have one reference, but no parent left, while in the example
> below :
are you sure about the above?
if (!prev_parent && pd->parent_sunk) efl_ref(obj);
so if there was no previous parent (this case...) only if parent_sunk is set
to we add the ref (rather than transfer it). so basically parent_sunk will be
set if you did an efl_add with a non-null parent, or you used efl_add_ref().
> obj = efl_add(CLASS, some_parent);
> efl_del(obj);
>
> The object will have been properly destroyed. This kind of problem happen
> easily in our API when we actually return a new Eo object. Depending on how
> we create it, its reference count might change. My personal take is that
> efl_del should not do anything on the parent. If we give an object to be
> managed by the parent, del should not be the one touching it. The parent
> should. So I would argue that efl_del should just be efl_release + efl_unref.
See my reply to andy about this right above and how having a NULL parent during
destruction is a major pain... :)
> > If we are delegating to a parent to manage the lifecycle of the object then
> > we should step away from the reference and forget it - that is the most
> > "convenient" behaviour I guess.
> >
> > if:
> > efl_add always returned an owned reference and took no parent
> > efl_add_child never returned an owned reference and required a parent
>
> This seems to match the change we think are necessary to efl_del.
i really dislike the idea of efl_add_child(). see my other replies to andy.
this will be 90-99% of all adds. adding as a child to something. don't make it
longer. but the change to this code will be a lot of work and painful. and i
doubt it's really any different to parent being just NULL or non-NULL (and
leads to 4 add funcs instead of our current 2).
> > then:
> > efl_add_ref* would no longer be required right? (if the binding requires a
> > ref after efl_add_child we have efl_ref that it could wrap up)
>
> We could still provide an efl_add_ref helper in C too, but otherwise yes to
> your point.
>
> > efl_del would take a reference and dec (probably not needed as we have
> > efl_unref?)
> > efl_del_child seems unlikely to be needed as all that is left is hiding
> > which is a graphics call, not an eo lifecycle one.
>
> I am not a fan of the idea of an efl_del_child, but as it would be an inline
> helper, it can be done later if we feel it is useful.
>
> This proposal would work for binding. Right now, they rely on efl_unref and
> can't call efl_del due to the unpredictable lifecycle that result of it,
> cleaning that, clean also the other side of the confusion by making efl_add
> more rigorous in its behavior.
>
> 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
>
--
------------- 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
