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.
Unrelated, and I may start another thread about it, I've been thinking
about it for the last few days following both the eo_del() discussion
and this one, that maybe we should change it so we can just unref to
delete an object even if it has a parent. I.e the parent ref is shared
with the "C ref" (the implicit ref we have in C). I need to think about
it more, but that will solve the caveat above and will let us drop
eo_del() completely.
Just a thought.
--
Tom.
------------------------------------------------------------------------------
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
