RE: Regarding the name 'pairs'

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

But how would you have a generalised name that would be appropriate in
diverse cases? If there was only one iterator, this would work, call it
something generic like "iter", but if you have two (as at present) you need
to distinguish them by function and this raises the question, why not three
or four? The other problem is that it is the name of the library function
("pairs" or "ipairs") that the "user" sees, not the name of the
corresponding (proposed) metamethods.

On the "__iter" proposal this would work exactly like the "__call" trick
except that "__iter" would apply in the context of generic for only, while
"__call" would continue to apply in all other cases. So you would be able to
pass parameters to the iterator (more formally the "iterator factory") just
as you can now with the "__call" trick.

It is important to realise that the "__pairs" and "__ipairs" proposal is not
just the "__iter" proposal with a different name. The latter requires core
language changes while the former is a very shallow and minor change which
effects only the "pairs" and "ipairs" functions in the base library - they
would delegate to the like-named metamethods if present or do what they do
now if not. This is similar to the way the "__tostring" metamethod works
with the "print" library function.

I am coming round to the attractions of the "method" proposal for multiple
iterators - the one where you can write:

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

All this requires is a change to the parser so it does not require the empty
parenthesis for a method call when the only passed parameter is the "hidden"
object reference. This approach has the advantage of allowing us to define
as many iterators (iterator factories) as we want and call them whatever we
want.

> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
> bounces@bazar2.conectiva.com.br] On Behalf Of TNHarris
> Sent: 10 September 2009 21:24
> To: Lua list
> Subject: Re: Regarding the name 'pairs'
> 
> On Wed, 9 Sep 2009 10:05:08 +0100
> "John Hind" <john.hind@zen.co.uk> wrote:
> >
> > 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.
> >
> 
> Well, I'm only concerned about the names, not the form of the
> metamethods. And I concur with the reasoning for doing away with the
> implicit iterator. It's better to be explicit than to have hidden
> magic.
> I don't consider it bloat.
> 
> I just anticipate someone expecting that "pairs" can only be used when
> the data is arranged as keys and values. With that confusion the
> metamethods are likely to be misused or ignored when they shouldn't be.
> Whatever it's called, though, I think the protocol is fine.
> 
> Also, it occurs to me, could "pairs" take extra arguments that are
> passed to the metamethod? Although I can't think of a concrete example
> where it would be needed, so maybe that's a misfeature after all.
> 
> -- tom
> telliamed@whoopdedo.org