On Sat, 18 Feb 2012 14:46:36 +0100 Vincent Torri <[email protected]> wrote:
> hey
>
> does the below break something ?
>
> Vincent
>
>
> Index: src/lib/edje_lua2.c
> ===================================================================
> --- src/lib/edje_lua2.c (revision 68106)
> +++ src/lib/edje_lua2.c (working copy)
> @@ -2930,16 +2930,16 @@
> {
> Edje_Lua_Obj *obj = (Edje_Lua_Obj *)lua_touserdata(L, 1); //
> Stack usage [-0, +0, -]
> Edje_Lua_Evas_Object *elo = (Edje_Lua_Evas_Object *)obj;
> - Evas_Coord x1, y1, x2, y2;
> + Evas_Coord xx1, yy1, xx2, yy2;
>
> if (!_elua_isa(obj, _elua_evas_line_meta)) return 0;
>
> - if (_elua_scan_params(L, 2, "%x1 %y1 %x2 %y2", &x1, &y1, &x2,
> &y2) > 0)
> + if (_elua_scan_params(L, 2, "%x1 %y1 %x2 %y2", &xx1, &yy1, &xx2,
> &yy2) > 0)
> { // Stack
> usage [-0, +0, m] unless it's in a table [-4, +4, e]
> - evas_object_line_xy_set(elo->evas_obj, x1, y1, x2, y2);
> + evas_object_line_xy_set(elo->evas_obj, xx1, yy1, xx2, yy2);
> }
> - evas_object_line_xy_get(elo->evas_obj, &x1, &y1, &x2, &y2);
> - _elua_ret(L, "%x1 %y1 %x2 %y2", x1, y1, x2, y2);
> + evas_object_line_xy_get(elo->evas_obj, &xx1, &yy1, &xx2, &yy2);
> + _elua_ret(L, "%x1 %y1 %x2 %y2", xx1, yy1, xx2, yy2);
> //
> Stack usage [-8, +9, em]
> return 1;
> }
That's not changing the text, which is the names and types of the Lua
table fields being passed back and forth, hence the API the Lua side
expects. So it's not breaking anything. The local variables can be
named anything.
Though I'm not so sure that changing local variable names to avoid
using the very obscure and badly named y1 global variable, then
replacing it with a slightly less obscure and badly named yy* variable
that might be used be lexers and parsers, is such a good idea.
Yes, I'm actually working on a project now that uses lexers and parsers
that like to use lots of yy* names, and mixing it with EFL Lua code.
It's just a warning, only one warning in the entire library, nothing
is actually broken. Anyone that wants to actually use obscure maths
functions probably wont suffer from any real problem coz we have a
single local variable that's not going to be anywhere near their code.
I certainly don't think we will EVER need obscure maths inside that
line drawing wrapper function.
It wont actually break my lexer and parser either, even if it does
cause more warnings. shrugs
If you really insist, just change the local C y1 variable to something
like -
y1_its_not_a_fucking_bessel_function
No need to change the others, they are innocent.
What's the point of variable scoping rules if you can't use them?
What's the point of fixing something that's not broken?
I'm not buying the argument that all those warnings are gonna obscure
real problems, there's only one warning, and there's no real problem.
lol
Otherwise we are just letting the compiler bully us into making the
code not so clean to read. It's good that the Lua names match up with
the C names, less confusing, neat, clean. I can live with one tiny
wart caused by obscure maths functions we will never use.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
