Default value mechanism in Lua using metatables

Question

I am writing a couple of functions accepting tables as input parameters. These tables constitute a range of options, which should either be given or inferred from default tables.

Concrete use cases can be found in the unit tests below.

The main question: Is the code idiomatic Lua – especially the use of metatables?

Code

local defvalue = {}
--[[
 Provides a means to fill a table with default options if they are not
 already present.
 This function is based on meta tables and their __index() function.
 table: Your (input) table.
 defTable: A table containing all default values.
 recursive: A boolean indicating if sub-tables should also be bound to the
 values found in defTable.
--]]
function defvalue.bind_table(table, defTable, recursive)
 local mt = {
 __index = function (table, key)
 return defTable[key]
 end
 }
 setmetatable(table, mt)
 if recursive then
 for key, value in pairs(table) do
 if type(value) == "table" then
 defvalue.bind_table(table[key], defTable[key], true)
 end
 end
 end
end
return defvalue

Unit tests (using luaunit):

require('luaunit/luaunit')
local defvalue = require('defvalue')
TestDefaultValue = {} -- class
 function TestDefaultValue:testDefaultValue()
 local actualTable = {}
 local defTable = {
 property = "value"
 }
 defvalue.bind_table(actualTable, defTable, false)
 assertEquals(actualTable["property"], "value")
 end
 function TestDefaultValue:testRecursiveValues()
 local actualTable = {
 -- test merging of sub-tables
 secondSubTable = {
 }
 }
 local defTable = {
 subTable = {
 property = "value"
 };
 secondSubTable = {
 secondSubProperty = "secondSubValue"
 }
 }
 defvalue.bind_table(actualTable, defTable, true)
 assertEquals(actualTable["subTable"]["property"], "value")
 assertEquals(actualTable["secondSubTable"]["secondSubProperty"], "secondSubValue")
 end
 function TestDefaultValue:testNonRecursiveValues()
 local actualTable = {
 subTable = {}
 }
 local defTable = {
 subTable = {
 property = "Hello World!"
 }
 }
 defvalue.bind_table(actualTable, defTable, false)
 assertEquals(actualTable["subTable"]["property"], nil)
 end
 function TestDefaultValue:testDynamicChange()
 local actualTable = {}
 local defTable = {}
 defvalue.bind_table(actualTable, defTable, false)
 assertEquals(actualTable["property"], nil)
 defTable["property"] = 42
 assertEquals(actualTable["property"], 42)
 end
 function TestDefaultValue:testPropertyShadowing()
 local actualTable = {
 property = "value";
 subTable = {
 subProperty = "subValue"
 };
 secondSubTable = {
 secondSubProperty = "secondSubValue"
 }
 }
 local defTable = {
 property = "hello";
 subTable = {
 subProperty = "world"
 };
 secondSubTable = 42
 }
 defvalue.bind_table(actualTable, defTable, true)
 assertEquals(actualTable["property"], "value")
 assertEquals(actualTable["subTable"]["subProperty"], "subValue")
 assertEquals(actualTable["secondSubTable"]["secondSubProperty"], "secondSubValue")
 end
-- class TestDefaultValue
LuaUnit:run()

• hjpotter92: You can pass value instead of table[key] in defvalue.bind_table(table[key]
• hjpotter92: Also, table is a reserved keyword in Lua. Use some other variable name instead :)
• Etan Reisner: Technically table is simply a default module/global but the same remedy is correct. =)
• Etan Reisner: It might be good to test that defTable[key] is a table in that recursive loop too. If it isn't the lookup for a default value later might error.
• Etan Reisner: If you comment out secondSubTable from actualTable in that test and run it you get an error because you cannot index a number value. That was my point.

Answer 1

If you comment out secondSubTable from actualTable in the testPropertyShadowing test and run it you get an error because you cannot index a number value.

The problem is that you are assuming that the replacement value will be index-able but not all values are. Tables, strings and custom userdata can be indexed but functions, numbers, and nil (by default at least) cannot be.

You might want to consider checking for the default being a table (testing for userdata requires trying it in a pcall I believe and is probably not worth it). Alternatively, you could leave it alone and let people use anything they can index and keep both parts if they use something else.