lua-users home
lua-l archive

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

The argument for having support for __iter is that if one starts to build iterations via sequences of filters, maps, and so forth then __iter allows one to avoid having to tack something on at the end to actually convert to iteration form while at the same time avoiding the performance costs of going through the __call metamethod lookup on every loop iteration.

The expense of doing this is the extra opcode at the beginning of a for loop to see whether the first argument to the for loop has an __iter metamethod and if so calling it.

This arguably comes down to a question of how much Lua should embrace an object-oriented approach to operations and how much it should stick to a more procedural/functional approach. __iter suggests that we think about for as taking iterable objects.

While on the subject of iteration, at the expense of probably breaking a number of iterator implementations, it seems like it would be nice if one could signal done by having the iterator return nothing instead of nil. That way one could build iterators that did in fact return nil. I don't have a good example of usage handy, but imagine wanting to return just the values in an array over a range. The work around right now is to return an extra initial parameter and simply ignore it.

In particular, here is a semi-desirable use case:

	for v in ... do
		-- process varargs

This doesn't iterate the varargs because it actually means use the ... parameters as the arguments. Hence, we probably need some other syntax anyway such as:

	for v in iter( ... ) do
		-- process varargs

It isn't a huge burden to have this also return an index which can then be ignored, but the index might be seen as a distraction:

	for _, v in iter( ... ) do
		-- process varargs

With or without the change to support nil values from iterations, some way to iterate (and for that matter index) ... would be really nice since use of select tends to lead to quadratic time complexity.