RE: Regarding the name 'pairs'

["John Hind" <john.hind@...>]

I could not agree more - I think this proposal is a very bad one and I am
dismayed it is going forward. Pairs and ipairs only makes sense for the
generalised tables of base Lua. If you are specialising tables (or userdata)
with metamethods, it is very unlikely these will still be relevant: you
might want one or many iterators and "pairs" or "ipairs" might, but probably
will not, be relevant names.

I would prefer a single __iter metamethod with deeper language integration
so we can write:

for v in myobject do print(v) end

If you want more than one alternative iterators, implement these as methods:

for v in myobject:myiterator do print(v) end

I can see that __pairs and __ipairs is seen as a minimal innovation which
can be implemented at the "library" level (similar to __tostring) rather
than in the core language. However I agree that these simply do not make any
sense in expressive terms.

> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
> bounces@bazar2.conectiva.com.br] On Behalf Of TNHarris
> Sent: 08 September 2009 23:47
> To: Lua-l
> Subject: Regarding the name 'pairs'
> 
> At the moment, the functions pairs and ipairs do just what they're
> named. But the metamethods __pairs and __ipairs will generalize this so
> any table or userdata will be iterable in a standard way. Except,
> there's no reason why an iterator should be returning a "pair", is
> there? A relational DB cursor, when iterated, would return the
> columns for each row. That could be any number of values, depending on
> the query.
> 
> If the names remain "pairs" and "ipairs" in 5.2, it would be an
> anachronism, wouldn't it? Could a more appropriate name be adopted when
> the new metamethods are added? So future code will be more readable.
> 
> Possible alternatives are "iter", "iterator", "each", "items",
> "enumerate" (for ipairs).
> 
> -- tom
> telliamed@whoopdedo.org