 |
lua-l archive |
|
|
||
|
On Aug 1, 2014 7:08 AM, "Philipp Janda" <siffiejoe@gmx.net> wrote:
>> 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 ...
Concretely: the new ipairs() is underspecified such that it no longer supports lazy-loading of tables/userdata. I can't tell whether __index or __len will be called first.
Say you have a table incompletely loaded from the string "abcde":
t = {"a", !incomplete}
When the value of t[3] is used, this becomes
t = {"a", "b", "c", !incomplete}
However, as soon as you call for #t, the lazy loader needs to complete far enough to know the final length. For many table types, this means completing the load:
> #t
5
t = {"a", "b", "c", "d", "e"}
Creating an array view of a linked list (possibly from C) is another example of where lazy loading might be used.
A long time ago I built a lazy XML parser. But it was long enough ago it had its own ipairs()-like global anyway. So I obviously can *survive* without __ipairs. :-)
Jay
(I am amused and a little sad that http://lua-users.org/wiki/LazyTree says "Last edited February 28, 2004")