Re: [ANN] Lua 5.3.0 (alpha) now available

[Jean-Luc Jumpertz <jean-luc@...>]

Le 1 août 2014 à 13:07, Philipp Janda <siffiejoe@gmx.net> a écrit :

> Am 01.08.2014 11:49 schröbte Jean-Luc Jumpertz:
>> 2) IMO the new behavior of ipairs is simple and consistent (even if different of the 5.2 behavior in a few corner cases).
> 
> The new `ipairs` stops at the first nil value for normal tables, and at `#t` for tables with `__len` or `__index`. So it's already twice as complex as the obvious alternative: stop at the first nil value, period. Works better for something like linked lists, too, where calculating the length is expensive ...

Correct me if I'm wrong, but
- for plain tables without '__len' nor '__index'  metamethod, the performance cost and behavior are exactly the same as in 5.2 (function ipairsaux_raw);
- defining a '__len' metamethod allows to execute a for loop on a table with holes in it (which I consider as a real progress!)
- so the only case where there actually is a performance penalty is on a table with __index defined and not __len. I wonder if there a many examples of this case...

>> And btw testing the  '__len' and '__index'  metamethods in function 'luaB_ipairs' has an almost null performance cost and gives you additional flexibility, so what would it bring to restrict this test to the '__len' metamethod, as Philipp Janda proposed? :-)
> 
> It's useless code that causes one extra case of undefined behavior, so why keep it? And what's the additional flexibility?

The additional flexibility is to allow you to freely define the values you want to return for table[i] and to keep it consistent between direct accesses like << a = my_table[i] >> and for loops like << for i, v in ipairs(my_table) >>, even if you don't redefine __len

> The performance cost I mentioned comes from the repeated calls to `luaL_len` and has nothing to do with the metamethods you check for.
Sure. I wasn't arguing on that. :-)

Jean-Luc