Getting and Setting a tabled value

[suicidalkatt]

Basically I have a table of strings that are the same as the index to a saved variables table.

I'm not sure how to go about writing the proper function to set and get the values in of the saved variable table using the table of strings.

local example = {
    profile = {
        helper = {
            enable = true,
        }
    }
}
 
local index = {
    "profile",
    "helper",
    "enable"
}
 
local function GetValue(t) -- This Seems to work
    if type(t) == "table" then
        local DB
        for k, v in next, t do
            if not DB then
                DB = example[t[k]]
            else
                DB = DB[t[k]]
            end
        end
        return DB
    else
        return example[t]
    end
end
 
local function SetValue(t, val)
     -- Do things here???
end

[Resike]

Phanx has some awesome functions for this.

Check this thread:

http://www.wowinterface.com/forums/s...ad.php?t=44038

However i might missunderstood what you really want to do.

[suicidalkatt]

Originally Posted by Resike Phanx has some awesome functions for this. Check this thread: http://www.wowinterface.com/forums/s...ad.php?t=44038 However i might missunderstood what you really want to do.

That's just a standard copyTable function that preserves the initial 'default' table.

My 'GetValue' and 'SetValue' would only affect a single value within the main table with all the various values.

You'd get to the single value within the main table with a small index table in the example.

My only issue is setting that value with an index table without having to do something less 'clean' in my eyes like this:

local function SetValue(t,val)
    if type(t) == "table" then
        local a,b,c = t[1],t[2],t[3]
        if c then
            example[a][b][c] = val
        elseif b then
            example[a][b] = val
        elseif a then
            example[a] = val
        end
    else
        example[t] = val
    end
end

[Resike]

What do you think about something like that:

master = {
    key = {
        key2 = "Hi!"
    }
}
child = { }
setmetatable(child, {__index = master})
 
child.key.key2 = "NOHIFORU"
 
print(child.key.key2) -- "NOHIFORU!"

[suicidalkatt]

I'm fairly sure using a metatable would be the best, but I've not worked much with it to really get the just of how to put it into code.

[Vrul]

Here a simple version of what I think you want.

local function GetValue(table, keys)
    local value = table
    for index = 1, #keys do
        value = value[keys[index]]
    end
    return value
end

local function SetValue(table, keys, value)
    for index = 1, #keys - 1 do
        table = table[keys[index]]
    end
    table[keys[#keys]] = value
end

[suicidalkatt]

Originally Posted by Vrul Here a simple version of what I think you want. local function GetValue(table, keys) local value = table for index = 1, #keys do value = value[keys[index]] end return value end local function SetValue(table, keys, value) for index = 1, #keys - 1 do table = table[keys[index]] end table[keys[#keys]] = value end

Interesting approach, I'll have to alter it a bit to be able to pass the DB into the functions.

[Phanx]

Why do you need to pass the db into the get/set functions? It's not like the path to the db (for AceAddon/AceDB) changes during gameplay; it's always located at MyAddon.db.profile, so just use that in your functions.

Also, the functions Vrul posted will only work if your options table structure matches your db table structure exactly.

Finally, AceConfig doesn't limit you to one setter function per options table. Rather than trying to shoehorn every possible scenario into one function, you are probably better off writing more specific functions tailored for each option group, or even each individual option.

[suicidalkatt]

Originally Posted by Phanx Why do you need to pass the db into the get/set functions? It's not like the path to the db (for AceAddon/AceDB) changes during gameplay; it's always located at MyAddon.db.profile, so just use that in your functions. Also, the functions Vrul posted will only work if your options table structure matches your db table structure exactly. Finally, AceConfig doesn't limit you to one setter function per options table. Rather than trying to shoehorn every possible scenario into one function, you are probably better off writing more specific functions tailored for each option group, or even each individual option.

I'm aware, I didn't end up trying to pass it into the function. Just declared locally instead. I do have other functions depending on what they're going to be intended for (color values for example).

I've been completely restructuring a lot of code so simplification feels amazing.

After a bit of researching metatabling would not have worked as cleanly.

[Phanx]

Using a single mega-function that handles every possible case is generally not a "simplification" over using multiple individual functions that each handle a few specific cases. If you don't look at your code for 6 months, are you going to remember what all the loops and other convoluted code in your mega-function even do? If not, you probably shouldn't write it that way in the first place.

[suicidalkatt]

Originally Posted by Phanx Using a single mega-function that handles every possible case is generally not a "simplification" over using multiple individual functions that each handle a few specific cases. If you don't look at your code for 6 months, are you going to remember what all the loops and other convoluted code in your mega-function even do? If not, you probably shouldn't write it that way in the first place.

I've since dropped down from 9 or 10 functions down to 5, it consolidated quite a few.

Most of those 'few functions' you spoke about are directly in the options table and are not a locally declared.

I feel that the change to this function was the right choice.

[Phanx]

Well, as long as you're aware that what you're doing is purely stylistic, and offers no real functional benefit, I guess you can feel however you want about it.