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
