lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

Thank you for comments and discussions even my
post is not well written. Please let me describe more.
Once I thought the same way as your comment.
For tables, an integer handle is not always necessary.

  el_setnum(el_field(el_var("user"),"uid", 9601);
  el_setstr(el_field(el_var("user"),"name","my_own_name");

  int uid=el_num(el_field(el_var("user","uid"));
  char *name=el_str(el_field(el_var("user"),"name");

For a 2-dimensional array like mx={ {11,12}, {21,22} }

  int v=el_num(el_index(el_index(el_var("mx"),1),2);  /** v=12 **/

These are a part of my working programs, and I thought
they might grown up to be useful to someone.
I also think it is not very attractive for trained Lua-users.
One issue is that they are quite inefficient.
For example, a table "user" will be used very often, it should be
loaded on the stack, that ensures quick access to its field.
That is a very nice feature of the standard Lua API
and actually makes Lua different from other languages.
But not all people understand this point and
feeling that stack management is somewhat tough.

On 08/06/03, at 0:14, Martin wrote:


To make it even simpler I would suggest to hide el_val() function from
user. So one can write:
   int nframe_inlua = el_num("nframe");
   char * title_inlua = el_str("title")


The other idea of easier API is to take a parser for an expression
like a case with Python for example.

   v=elx_num("mx[1][2]")

If the string contains [(., it may calls a Lua parser.
I think it was already discussed in this mailing list before,
it does something like : dostring("return "..str)) in C.
This might be widely used and even Lua function can be
called. But I miss nice things in Lua API.


I thing that introducing integer handle would unnecessary confuse
_beginner_ users. Users more experienced should anyway use
standard API.


This is a compromising method. The integer handle is nothing
but a stack index. With the standard API, we can take
a fixed integer assigned to a table.




for ease of use. But you should than emphasize very loudly and
very often in manual for your implementation that it is just
simplified and very reduced set of lua. I would think  very hard
if there should be implemented any more than this 8 functions:


Sure. I will make an appropriate note.


And of course you need to handle errors in some graceful way in all
of your functions (if that is possible in general way). There are
two ways I can think of:
 - ignore all errors (not very good, I guess)
 - exit the application (not very user friendly)

If user need more functionality there should be strong warning
that it is needed to use standard API and not to mix easy_lua
API with standard one. If facilities provided with easy_lua
are enough for task under the hand than OK, if you need more
do not use easy_lua at all!


I agree that error handling is important.
It really helps debugging the code.
In fact mixing the standard API and my functions may introduce
unexpected error. I have to check possible problems.


  ip=el_var("print");
  el_pushnum("something");	/** the same as official API **/
  el_pushstr(10.0);
  ir=el_call(ip);
  el_num(el_index(ir,1)));      /** if return values exist **/


This is one example where I think that your proposed easy_lua API
does not bring anything simpler to user than there already is.
.......
It is basically line for line replacement and I do not think that
is of any benefit (on the other hand it can be confusing for beginner
in that way that it bring two alternative way to do the same thing:
one of which is official way and the other one that is no simpler
than first one.


It only helps to count number of arguments and
successive stack management for LUA_MULTIRET.


If you want to simplify function call you should restrict yourself
only to most common cases. Something like this:
     double el_num_call_num(double arg);
     char * el_string_call_string(char * arg);
perhaps even:
     double el_num_call_string(char * arg);
     char * el_string_call_num(double arg);
or some other combinations that you find most needed. But do
not get carried and implement lot of combination (more than
one argument of different types, function that return more
than one value etc...)


I also considered about that, but I choose the same way as the
standard API. Because people still use
lua_dostring(L,"print()") and sprintf().


Note that even accessors to table are crippled:
values stored and fetched can be only numbers and strings, not
booleans, function, tables ... Also keys are only string, not all
the other types (numbers are used very often for example).

For your proposed approach to function calling I have
some observations/questions:
- it seems you swapped arguments for el_pushnum and el_pushstr


exactly, sorry about that.


- standard function print actually does not return any value
  (but you have covered that case with comment at last line
  so it is ok)


yes, it was not a good example. It uses LUA_MULTIRET
and this case return value table is empty that will not
come on failure.


- in function el_index what is meaning of second argument?


an integer index to the table.　This case the table holds
the return values of the Lua function.
el_index(t,idx) does something like:
		lua_puhsnumber(L,idx); lua_gettable(L,t);


Again to repeat myself. I think you should limit yourself to
implement only very small set of functions that will cover
most often used cases of storing and fetching values form
global variables and tables. If you will try to every feature
(or lot more than accessing variables and perhaps call to simple
functions) my belief is that it will be not easy API anymore. It
will be just different than the official one. And that will do
no good to anyone.

Misko


I understand your point. I need to describe limitation of this
approach and what is provided. Please let me have time for that.
I think that my proposal is trying to find a method, a milestone
of programming work for beginners, who eventually use the
standard API.
I think that those who trained the assembly language programming,
Lua API is just fine, while others have hard time.
In the case of graphics library, WIN32 API provides
everything, but many people prefer simplified functions.
Thus, my proposal is simply to forget about stack managements.
But we can still take advantage of the Lua stack, so there could
be different levels of exercise on programming with the standard
API. I hope it contributes to that kind of idea.

---Yutaka Ueno