Thanks for clearing things up. On 10 May 2016 at 20:18, Tom Hacohen <t...@osg.samsung.com> wrote:
> > On 10/05/16 11:52, Jean-Philippe André wrote: > > Hey Tom, > > > > On 10 May 2016 at 19:06, Tom Hacohen <t...@osg.samsung.com> wrote: > >> I already described a better scheme in the email I referred to > >> previously. It solves all teh problems for both proxy and normal objects > >> and both use cases, single and multi. All of this while maintaining > >> properly defined lifecycle that just works. Why not that? > >> <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel> > >> > > > > Could you repeat your proposal clearly? > > This mail thread is not readable anymore since you proposed eo_part > > (reusing eo_super bit), GC, implicit unref, and adding part= args. > > > > I was referring to the implicit unref. The way it will work is as follows: > > Usage: > > text_set(content_get(obj, "part"), "bla); > > or > > tmp = eo_ref(content_get(obj, "part")); > text_set(tmp, "part"); > color_set(tmp, ...); > eo_unref(tmp); > > > Implementation: > If it's a real internal object, you do nothing internally. The object is > alive anyway so for the 1 call it will just work without needing to > ref/unref. > For the multi call the user will ref and unref on its own, so he can be > sure the object is alive. > > If it's a proxy object, you will be implementing it as a special proxy > object anyway, so you control the implementation. In the implementation > you just add a efl_proxy_unref() at the end of each implementation. This > function only calls eo_unref() only once per efl_content_get() in order > to allow multiple calls. > > So essentially with the above example it'll look like: > > > tmp = eo_ref(content_get(obj, "part")); // Eo_ref: 2 // proxy_ref: 1 > text_set(tmp, "part"); // Eo_ref: 1 // proxy_ref: 0 // because > eo_proxy_unref(); was called. > color_set(tmp, ...); // Eo_ref: 1 // proxy_ref: 0 // because > proxy_unref() didn't do anything. > eo_unref(tmp); // Eo_ref: 0 (deletion) > > This will solve it. > > The only caveat is that you need to make sure that the proxy object > doesn't have an eo parent so it is deleted based on the unrefs and won't > stay alive. > > This will let you have proper lifecycle handling (like any eo object) > without any issues. Everything will just remain the same. > This is conceptually similar to the temp flag raster mentionned. I think his first and only mail about it was a quick thought, we talked more about it later (orally). One question is where is the implicit unref. Is it part of the proxy object implementation, ie in every function, or somehow in eo.c. IOW who calls efl_proxy_unref? Unrelated, and I may start another thread about it, [...] > <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel> > Yes, eo_del belongs to another thread. -- Jean-Philippe André ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
