On Tue, Jul 23, 2013 at 11:47 AM, Tom Hacohen <tom.haco...@samsung.com> wrote:
> On 12/07/13 07:42, Carsten Haitzler (The Rasterman) wrote:
>> On Mon, 08 Jul 2013 18:00:15 +0100 Tom Hacohen <tom.haco...@samsung.com> 
>> said:
>>
>> ok. looked at eo2test.c
>>
>>     eo2_do(obj,
>>           a = inst_func(eo_o, 32);
>>           inst_func(eo_o, 10);
>>           b = inst_func(eo_o, 50);
>>           );
>>
>> first... passing in eo_o... should probably go away. ie
>>
>
> Gustavo suggested (but he's too lazy to write an email about it and I
> need reminders so I'm sending it) that we use a stack to keep the eo
> pointer. This means we won't expose the eo pointer anymore (which
> doesn't matter, but whatever), we will be able to have function
> signatures the way we want them, e.g: evas_object_move(x, y), instead of
> passing anything and it should be cool in general. I'm happy, and will
> incorporate that unless objected. As long as we pre-allocate the stack
> it shouldn't come at a big cost.
>
> What do you guys think?

just a reminder this stack should be per thread, in a
thread-local-storage region.

for single calls it should be worse as we set-call-unset, but for
multiple calls that may pay off. The readability is much better this
way, at least it would be similar to previous code where we got the
private data.

the con I could see is we loose validation in the caller, you'd need
to validate in the function... Example:
    eo_do(evas_obj, ecore_timer_interval_set(10.0));
this would still call directly ecore_timer_interval_set(), which
internally would get the eo_o, which should be validated and return if
not right. All in all that would be the case, as
ecore_timer_interval_set() would need to get the actual method
(virtual) to call.

I did not read the whole thread, so that may be addressed in another
way. From the above example this could happen as well, inst_func()
also has a potential of not being a method of obj.


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to