Re: ipairs in Lua 5.3.0-alpha

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

2014-08-20 10:55 GMT+02:00 David Demelier <demelier.david@gmail.com>:
>
> Le 19/08/2014 18:48, Dirk Laurie a écrit :
>
>> 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.
>
>
> Yes but for userdata, it's quite easy to create a indexable object by just
> putting a luaL_Reg array as the __index table, now you need to implement
> this as a function which must take care of the index value if it's an
> integer or not... This also setup a little overhead due to the function
> call.

In the other thread with this subject, Roberto said:

> I really do not think that ipairs + __ipairs is a good generic iterator
> interface. That was never the intention when we created __ipairs.
> Among other problems, it forces an object to have only one "true"
> iterator; it is too "object" centric.

That's why I have started to switch my mindset from hoping to
get __ipairs retained to working out what life without __ipairs will
be like.