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 ;)
> 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
>
> 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 !!)
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!
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
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--- Hell'O from Yverdoom
Jérémy (jeyzu)
------------------------------------------------------------------------------
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
