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);
);
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:
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
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 ...
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.
> Hey guys,
>
> The hero Jeremy Zurcher has been playing around and looking for ways to
> improve Eo and address all the issues that have been raised by everyone.
> We revisited some old ideas, tried some new ideas and changed our
> compromises and preferences to better suit our needs (followed by the
> extensive trial period). We think we made things better and we'd like to
> hear your thoughts and suggestions.
>
> The code resides in devs/tasn/eo2. The differences are not major
> usage-wise (i.e eo_do), but are major internally and class-creation-wise.
> There's an example of the usage of the new API in the eo2test directory.
> The existing code-base hasn't been changed to use the new API, so
> there's not a lot to review.
> Eo2 is not complete, we'd like to hear your thoughts before finishing
> things.
>
> Major changes:
> 1. No more va_args, good ol' normal functions instead.
> 2. Functions are resolved in eo and then called directly, creating a
> "flatter" backtrace.
> 3. We can have return values (to some extent).
> 4. Less boiler-plate.
> 5. Looks like we'll be able to get rid of some code thanks to this change.
> 6. Possibly (probably) faster on platforms that pass parameters in
> registers.
> 7. Easier to do breakpoint on a specific eo_do call, instead of an
> implementation.
>
> What we'd still like to achieve:
> 1. Being able to drop the IDs in favour for more "friendly" IDs. It'd be
> best to find a way to use the function pointers (for example) as the
> IDs, but the problem is, that because function pointers are more
> "unknown" we can do less optimisations on them which we'd like to avoid.
> 2. Reduce more boiler-plate.
>
> Haven't been implemented yet: eo_do_super (among many other things).
>
> Additional comments:
> EO_FUNC - this one creates a function that resolves and returns the
> appropriate function. The functions created using this macro should be
> used instead of the current eo macros. This one can potentially be improved.
> eo2_do_start/end are just the entry/exit hooks of eo2_do (ref/unref and
> possibly other stuff in the future).
>
> Looking forward to hearing what you have to say.
>
> --
> Tom.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
