[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [Suggestion] Passing upvalues to load()
- From: Philipp Janda <siffiejoe@...>
- Date: Wed, 7 Oct 2015 04:06:53 +0200
Am 07.10.2015 um 02:29 schröbte Soni L.:
On 06/10/15 09:26 PM, Claire Lewis wrote:
How does order factor in, if the code refers to them by name? I think
I'm overlooking something.
In Rio Lua, the order is as they appear. So if a global access
appears before any other upvalue access on a function, _ENV is the
local u2, u3, u4, u5
print(u2, u3, u4, u5) -- _ENV is the first upvalue, because
"print" is actually "_ENV.print" (or "_ENV['print']")
Unless I'm missing something, I don't think this is reliable, that's
an implementation detail, and could change any future version, even a
patch release of 5.3.
The Lua 5.3 manual states: "Upvalues have no particular order, as they
are active through the whole function. They are numbered in an
I'd probably recommend finding a different way to achieve this for a
But it's resonable to assume they're consistent between dump and reload.
That's not the issue. The problem is between dump/load on one side and
the party who supplies the extra upvalues for load on the other side.
Using a table for named upvalues is only an option if debug info is
available in the bytecode, so IMHO there is no easy solution to this.