 |
lua-l archive |
|
|
||
|
Am 01.08.2014 11:49 schröbte Jean-Luc Jumpertz:
A few comments about the changes in ipairs in Lua 5.3.0 (alpha): (it seems that those were already in Lua 5.3 work 3, but I didn't notice them previously, and I didn't find many discussions on this in the lua-list or on google...) 1) I find that the deprecation of the __ipairs metamethod is a really welcome simplification.
That may be, but `__ipairs` is more flexible than the "count until `__len`" protocol.
Actually the __ipairs functions I had to write for various userdata types were all an almost exact duplicate of what is now function ipairaux in lbaselib.c. 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 ...
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 performance cost I mentioned comes from the repeated calls to `luaL_len` and has nothing to do with the metamethods you check for.
Jean-Luc
Philipp