lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Well you could implement this now with a metatable. It would probably just be faster as a global function getlocalbyname(name). Of course, this would be in terms of the debug interfaces, so it doesn't meet your "faster than debug.getlocal" requirement.

And consider the following: what happens if you insert a new key to the locals table?
> _LOCAL.foo = unpack -- allocates a local foo?
> _LOCAL[foo] = print -- allocates a local "named" by a function key?
> _LOCAL[1] = "bar" -- ???

On Mon, Jun 8, 2015 at 2:05 PM, Soni L. <fakedme@gmail.com> wrote:
I wish you could access your own locals with an _LOCAL[idx] that would be faster than debug.getlocal...

Not sure how that'd work if you local x = _LOCAL, or called a function with _LOCAL...

On 08/06/15 05:53 PM, Oliver Kroth wrote:
Yes,

the "local" in front of "func1" and "func2" has the effect that the names "func1" and "func2" are NOT members of _ENV. Instead they are converted to registers, i.e. anonymous stack offsets. Removing the "local":

function func1() print("
local func1") end
function func2() print("local func2") end

local fn = { "func1", "func2" }

for i = 1, 3 do
local func_name = fn[i]
pcall(_ENV[func_name])
end

should print

local func1
local func2

until you change the string literals, too :-)
pcall (null), which happens with calling pcall( _ENV( fn[3] ) is captured and returns false pus a string saying "attempt to call a nil value", which is ignored

--
Oliver


Am 08.06.2015 um 22:18 schrieb Milind Gupta:
Is there a problem doing it this way: ?

local function func1() print("local func1") end
local function func2() print("local func2") end

local fn = { "func1", "func2" }

for i = 1, 3 do
local func_name = fn[i]
pcall(_ENV[func_name])
end

On Mon, Jun 8, 2015 at 12:49 PM, Brigham Toskin <brighamtoskin@gmail.com> wrote:
If it makes sense, you may be able to cache these as locals and/or upvalues in some cases for a speed bump. You'll have to decide if it fits your project architecture though, i.e. used several times after lookup, rather than completely dynamical at each call site.

On Mon, Jun 8, 2015 at 12:25 PM, Dmitry Zaitsev <hhrhhr@gmail.com> wrote:
Thanks to all. Indeed, the search for local names was rather slow in the case of frequent use, so I will use the table of functions from the first example.

2015-06-08 22:18 GMT+03:00 Brigham Toskin <brighamtoskin@gmail.com>:
Oh, reflection. Yeah, forgot about that. Still, probably a bad idea to do this in a loop or frequently-called code, unless you're sure it won't bottleneck your code.

On Mon, Jun 8, 2015 at 12:13 PM, Paul K <paul@zerobrane.com> wrote:
> it is work, but I'm interested in the ability to call a local function:

You can iterate over local variables to find the one with the name you need:

local function func1() print("local func1") end
local function func2() print("local func2") end

local fn = { "func1", "func2", "func3" }

local function name2value(target)
  for i = 1, math.huge do
    local name, value = debug.getlocal(2, i)
    if not name then return end
    if name == target then return value end
  end
end

for i = 1, 3 do
  local func_name = fn[i]
  pcall(name2value(func_name) or error("can't find local "..func_name))
end

Paul.

On Mon, Jun 8, 2015 at 11:56 AM, Dmitry V. Zaitsev <hhrhhr@gmail.com> wrote:
> example with table of functions:
>
> local T = {}
> function T.func1() print("func1") end
> function T.func2() print("func2") end
>
> local fn = { "func1", "func2", "func3" }
>
> for i = 1, 3 do
> local func_name = fn[i]
> pcall(T[func_name])
> end
>
> it is work, but I'm interested in the ability to call a local function:
>
> local function func1() print("local func1") end
> local function func2() print("local func2") end
>
> local fn = { "func1", "func2", "func3" }
>
> for i = 1, 3 do
> local func_name = fn[i]
> pcall(func_name) -- ???
> end
>
> of course, I get an error "attempt to call a string value".




--
Brigham Toskin




--
Brigham Toskin



-- 
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.



--
Brigham Toskin