[simonw]

I quite like that the Lua API is a single function, because it means it completely forward compatible already - the Lua API won't have to have new methods added to it when Redis gets new commands.

[antirez]

Exactly, it also means: scripting engine completely decoupled from all the rest. Also it is much simpler to do things like dynamic execution of commands, redis(my_command,"var")... or alike.

[sztanpet]

But it is just as easy to do that will a full userdata in lua. You just hook up the newindex metamethod. Even more powerfull

[almost]

This seems like a really good reason, especially with Redis's focus on code quality and developer fun. That scripting.c is only 382 lines long is very cool :)

[sztanpet]

I cannot agree with that, it's just as easy to add new methods as to learn to pass a new string as the first argument. How is it more "forward compatible"?

[simonw]

When Redis adds a new command in the future, the Lua API code will already work with that new command without needing any modifications - hence forward compatible.

[LeafStorm]

You could implement a forward-compatible database function table like this:

  local function accesscommand (t, key)
    local f = function (...)
      return redis(key, ...)
    end
    t[key] = f
    return key
  end
  db = setmetatable({}, {__index = accesscommand})
  function db.hmset (key, values)
    local t = {}
    for key, value in pairs(values) do
      t[#t + 1] = key
      t[#t + 1] = value
    end
    redis("hmset", unpack(t))
  end

Any command without a function defined in the table would create a closure on the fly that calls that command like normal. (It also stores the closure in the table to speed up future calls.) Commands that could be implemented more elegantly using Lua semantics (like HMSET) have overrides defined in the db table directly, which prevents the closure-generating function from being called.