Re: ipairs in Lua 5.3.0-alpha

[Sean Conner <sean@...>]

It was thus said that the Great Rena once stated:
> 
> 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)

  You want map() and reduce(), not a loop.

  -spc