[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Considering keep track of the index of global table
- From: Dirk Laurie <dirk.laurie@...>
- Date: Thu, 16 Aug 2018 09:14:53 +0200
Op Do., 16 Aug. 2018 om 00:59 het Tim Hill <email@example.com> geskryf:
> > On Aug 15, 2018, at 9:17 AM, qtiuto <firstname.lastname@example.org> wrote:
> > 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  no less, that
uses the idiom of putting _ENV in the parameter list.
Raffiniert sein die Lua-Erfinder, aber boshaft sein sie nicht. —
 3rd ed, p147.