Re: Considering keep track of the index of global table

[Roberto Ierusalimschy <roberto@...>]

> > > While lua_load will always set the first upvalue of a dumped function to the global table, the actual index of the global table is related to the first time it's used in the function.If some local value is used
> > > first,then its upvalue index will be lower than _ENV.
> > > What's worse,if I use strip mode, I can't figure out the actual index of the _ENV when I load it.So, it would  better add one more int in dumped content to keep track of the global index and when load it, set its value to global table,rather than trying to figure out whether it has one more upvalue after undump, and setting the first value to the global value.It will cause a bug!
> > >
> > > The fix is little.However, I don't want to type it in my phone
> > I suggested something like this when I was writing a “deep” table dump function (so I could dump complete closures). It was politely declined.
> 
> As anything that would need an extra sentence in the User's Manual
> tends to be :-)
> 
> There are of course certain properties of global _ENV that are
> unilkely to be shared by other local variables,
> such as 'v._ENV == v'.
> 
> And there are programming habits that force _ENV to be the first
> upvalue, such as starting functions with 'local _ENV=_ENV'.
> 
> And there is a programming style, documented in PiL [1] no less, that
> uses the idiom of putting _ENV in the parameter list.

I think this discussion misses the main point. Functions that represent
chunks always have _ENV as the first upvalue, no matter what the
programmer writes. Much more often than not, load is used to load that
kind of "function" (whole chunks). The facility of setting the first
upvalue to the global table is directed to this (very frequent)
case. For any other case, the programmer should use 'debug.setupvalue',
independently of whether the upvalue is _ENV.

-- Roberto