lua-users home
lua-l archive

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


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")