On 21/07/13 14:18, Jérémy Zurcher wrote:
> Hello from my holiday in France (for the frenchies who know lofofora ;)
>
> On Friday 12 July 2013  15:42, Carsten Haitzler 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
>>
>>     eo2_do(obj,
>>           a = inst_func(32);
>>           inst_func(10);
>>           b = inst_func(50);
>>           );
>
> the declaration is
> EAPI int inst_func_set(eo2_a, int a, int b);
>
> expanded to
> EAPI int inst_func_set( _Eo *obj, Eo *objid, int a, int b);
>
> what I first proposed was using a second macro
>      eo2_do(obj,
>            sum = eo_call(inst_func_set, 32, 12);
>            a = eo_call(inst_func_get_a);
>            );
>
> would it be better ?
> (Tom, I don't love it, that's just handy ;)

I don't like it because it doesn't look like c code any more. This means 
that what Carsten is asking for can't be done.

>
>> secondly, having a = xxxx; with ; too.. is going to start encouraging people 
>> to
>> do really bad things like:
>>
>>     eo2_do(obj,
>>           if (inst_func(32) != 22) return;
>>           inst_func(10);
>>           b = inst_func(50);
>>           );
>>
>> and all sorts of hell is going to break loose here. i don't believe that as a
>> result of returns we can now sensibly handle method errors from an eo_do()
>> batch. if we are using returns for errors we SHOULD have something like:
>
> well the rule is really simple to document and explain:
>    use break not return in e eo2_do() construct

It's better to have enforcement by the compiler.

>
>>
>> Eo_Err err;
>>
>> err = eo_do(obj,
>>              a = inst_func(32);
>>              inst_func(10);
>>              b = inst_func(50);
>>              );
>> if (err.error == inst_func1_id) return; // inst_func1 method id is what 
>> failed
>
> we have no more function id in the latest prototype,
> but this disallow EAPI static inline func();
>
> I'm waiting for comments from Tom and others about this.
>
>> if (err.failedop == 2) return; // in a batch, operations are counted, 0, 1, 2
>>                                 // so op id 2 (last one) failed here
>> if (err.type == EO_ERR_INVALID_VALUE) return; // can put err inside a type
>> field.
>>
>> note that this is using an error return as a struct, not a basic type (int,
>> pointer, char, etc.), and this is perfectly valid and correct in basic c. 
>> it's
>> not an extension. we COULD pass in a ptr to the err struct too instead of 
>> using
>> a return.
>>
>> but... in the end the error is returned and deal with OUTSIDE of the eo_do()
>> block. so we guarantee to always exit the eo_do() block at the end safely and
>> handle refcounts properly. if people start putting arbitrary code inside the
>> block with returns and what not.. compilers will allow this in eo2... and we
>> will have problems. big ones. i can smell it right now. so i'd say dont 
>> allow ;
>> s and arbitrary code inside. use , i.e.
>>
>> Eo_Err err;
>>
>> err = eo_do(obj,
>>              a = inst_func(32),
>>              inst_func(10),
>>              b = inst_func(50),
>>              );
>>
>> ... needs some looking into maybe ...
>
> what does 'guarantee' and 'don't allow' mean ? I think no more than words in 
> an API doc.
> if users want to try wrong construction they still will be able to.
> (sure eo_do() is stronger in that case, compiler does not accept code in 
> varargs !!)

We can always have a mock static inline function that will get optimised 
out that is passed all the parameters so we will be able to enforce that 
no code is allowed there.

> So what matters is which one is the simplest to use and to document.
> for me it's clearly 'do not use return' btw what users and us will do is not 
> much than
> eo2_do(obj,
>          ret = eo_call(do_some, 133, 254);
>          if(!eo_call(try_this,435)) break;
>          ret = eo_call(all_perfect);
>          );
>
> no need to explain users how to handle the error code, no need for us to
> waste precious time checking last call status to know if we must break 
> eo2_do(…)
>
>>
>> my other reservation is that e are exposing the pointer to an eo obj TO the
>> application code.. and the objid stuff in eo was to try isolate this. this 
>> now
>> leaks it out into the app... allowing for abuse and misuse. that is a 
>> downside
>> of this.
>
> yes, I too dislike this, but don't think this is that harmfull.
> it's an opaque type, what could users do with it, free it ??
> bloody bastards may the gods punish them I'would say!

I agree.

>
> btw I tried to use an object context instead, see devs/jeyzu/eo2
> it looks like this (eo2_do() expanded):
>    ctx = eo2_do_start(obj_id);
>    my_eapi_func(ctx, args);
>    ...
>    eo2_do_end(ctx);
>
> the goodies are:
>    - no more object pointer leaking in user land
>    - detect a missing eo2_do_end() on the next call to eo2_do_start()
>    - cache the object data pointer
>
> ctx is not thread safe but could be

ctx has to be defined locally (and thus not thread safe anyway), because 
you may have a lot of eo2_do inside each other.

--
Tom.


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