Re: ipairs in Lua 5.3.0-alpha

[Dirk Laurie <dirk.laurie@...>]

2014-08-19 18:22 GMT+02:00 Rena <hyperhacker@gmail.com>:

> This is a good point as well: removing __ipairs makes it harder to make a
> custom object which "pretends" to be a table. E.g. if I want to retrieve
> each value from a database as it's requested. With __ipairs I can pass my
> object to code which simply expects "some iterable object"; without, that
> code needs to know *how* to iterate every type of object it might receive.
>
> I don't see a reason to remove __ipairs. It provides a common interface to
> iterate any object in order (whatever "in order" may mean for that object),
> just as __pairs provides a common interface to iterate a dictionary.
>
> I've stated before that I'm a big fan of duck typing, and removing generic
> metamethods in favour of everyone providing their own interfaces makes that
> more difficult. My code shouldn't have to care whether it's iterating an
> array or a database or a file; it should just be able to say "give me the
> contents in numeric order, one at a time", which in Lua is written:
> ipairs(Foo)

The rationale behind removing __ipairs says: provide your own __len
and __index in such a way that the items obj[1], obj[2], ... , obj[#obj]
gives the contents in numeric order, one at a time. Your postulated
database need not actually use __index for any other purpose: it's
just a function to return an item associated with the iteration index.

Roberto's most recent idea [1], which has received only approval so
far, is to let the iteration still bail out, like the raw-access ipairs did,
when the value is nil. If you want that to be the only way of stopping,
__len can simply return math.maxinteger.

[1] http://lua-users.org/lists/lua-l/2014-08/msg00446.html