 |
lua-l archive |
|
|
||
|
A couple more notes: On 27-Nov-05, at 2:16 AM, Rici Lake wrote:
(ipairs() needs to be modified as well, but I didn't do that. Oops.)
Actually, it's possible that ipairs() doesn't need to be modified aside from its name. Since the iteration state is now hidden, ipairs() ends up being ivals(), as it were, which is often what you want. (How often do you write: for _, v in ipairs(t) do ... end ?)
-----------------It could be argued, reasonably, that desirable though this change might be, it will break all code which uses custom iterators. That is certainly true, but I think it may well be worth thinking about for Lua 6.0. It would not be difficult to implement a compatibility layer, particularly if the syntax for 'for in' loops were changed; the compatibility layer would simply replace the provided iteration function with a function which duplicated the first result. (This wouldn't work with the change to the termination condition from nil to 'any false value', but that could probably be worked around as well; in any event, the semantic change is not critical. It just seemed more consistent since for loops are one of the few places where false and nil are distinguished.)
Examination of the benchmark code may show the difference in writing iterators for the two versions; it is not clear to me that the new version is that much simpler, but not having to write a closure wrapper does certainly help a bit. It also shows why I think that there should be a __pairs metamethod which provides the "default iterator" for an object type; look at the constructor for ordered tables for an example of where it would have been handy.
R.PD: lhf gently reminded me yesterday that my messages are often too long. Sorry. Obviously, I'm not doing very well at solving that.