Re: Slight discrepency in the documentation for

[Eric Raible <raible+lua@...>]

Mark Edgar <medgar <at> student.gc.maricopa.edu> writes:

> 
> Eric Raible wrote:
> > The first return value of pairs(t) is rather a private function that
> > invokes that same code (luaB_next) that 'next' invokes.  But it does
> > _not_ return 'next' per se.
> > 
> > So either the documentation should be fixed, or the following patch
> > could be applied which makes the reference manual true.  This patch
> > both the advantage and the disadvantage that if the value of 'next'
> > is changed, then pairs(t) will see that change.
> 
> Your patch will break if "next" is not available in the global table or 
> is reassigned to something else for some reason.
> 
> The following should work (untested!):
> [patch deleted]
> 
> With this change, the pairs upvalue is same function as _G.next instead 
> of a new one which refers to the same C function.
> 
> 					-Mark

But in my patch "next" _will_ be available in the global table.
It will in fact initially point to the "normal" value stored in _G.next.

And obviously it could break things if one redefines "next" inappropriately
(that's what I meant by "both the advantage and the disadvantage" in my
original post).

But that's true if one redefines any global inappropriately, right?
The only difference here is that breaking "next" breaks "pairs",
which is slightly less obvious than other cases.

Anyway, if we don't want that to be the case then the reference manual
ought to be changed.

- Eric