Refrincing end user crated tables?

Is it possible to refrince a user's table from in my own code? so my api can do things it needs to do while allowing the user to edit the tables they difined. The reason is I have a buttonAPI that uses metatables and usercrated variables to work. I want to be able to refrince those user created variables so as the users code edits the values my code will display the buttons correctly. The reason I want this is to add functionality for multiple monitors connected via side or network cable with a function or another user created variable with metamethod.

Link to the current verison of the API: http://pastebin.com/WC1JZwCx (I still need to do some tests to see if every thing works right.)

Just pass the table as an argument to the function, like you would with any other variable.

CometWolf, on 18 March 2014 - 06:39 PM said:

Just pass the table as an argument to the function, like you would with any other variable.

but would I have to have them run that function every time they update information?

Good API design would have all changes the user desires to make be made through calls to your API. You could watch the tables with a metatable __newindex setup, it's just not a good idea. Why are you trying to do this that way instead of using good API design?

Lyqyd, on 18 March 2014 - 07:02 PM said:

Good API design would have all changes the user desires to make be made through calls to your API. You could watch the tables with a metatable __newindex setup, it's just not a good idea. Why are you trying to do this that way instead of using good API design?

The API allows the user to crate a way to make a variable that controls a monitor for displaying buttons or labels, and what I would like to do is create a way for the user to have one call to cycle though all of the created variables, because if they use the run command on one of them only one monitor will be updated.

Termanater13, on 18 March 2014 - 06:45 PM said:

CometWolf, on 18 March 2014 - 06:39 PM said:

Just pass the table as an argument to the function, like you would with any other variable.

but would I have to have them run that function every time they update information?

No, but you would have to pass all tables to it. Unike most other variables, tables will still point to the same adress. This means any changes to the table will be visible from both inside and outside the api at the same time.

Alternativly, something like setmetatable(getfenv(2),{__newindex = function(t,k,v) if type(v) == "table" then –whatever your api does to tables here end}) might work. However getfenv(2) might be the os table, so maybe you'll have to use 3. Provided my understanding of getfenv is correct. I've never used it for anything other than getting the current environment.

Termanater13, on 18 March 2014 - 07:18 PM said:

The API allows the user to crate a way to make a variable that controls a monitor for displaying buttons or labels, and what I would like to do is create a way for the user to have one call to cycle though all of the created variables, because if they use the run command on one of them only one monitor will be updated.

Could you expand on this a bit more? It seems like it would simply be easier to create an API that handled multiple monitors and accepted a side name when creating a new button, so that it would be placed on that side. It wouldn't be terribly difficult to set up a function that would handle events coming in from multiple monitors and checking against the side name of each button. It just seems overly complicated to try to create an "API" that doesn't use API calls and instead tries to watch a table passed to it by the user. I think you're going down a road that will be unnecessarily troublesome when there are far simpler and more robust ways to accomplish the same goals.

Lyqyd, on 18 March 2014 - 07:55 PM said:

Termanater13, on 18 March 2014 - 07:18 PM said:

The API allows the user to crate a way to make a variable that controls a monitor for displaying buttons or labels, and what I would like to do is create a way for the user to have one call to cycle though all of the created variables, because if they use the run command on one of them only one monitor will be updated.

Could you expand on this a bit more? It seems like it would simply be easier to create an API that handled multiple monitors and accepted a side name when creating a new button, so that it would be placed on that side. It wouldn't be terribly difficult to set up a function that would handle events coming in from multiple monitors and checking against the side name of each button. It just seems overly complicated to try to create an "API" that doesn't use API calls and instead tries to watch a table passed to it by the user. I think you're going down a road that will be unnecessarily troublesome when there are far simpler and more robust ways to accomplish the same goals.

I save the side in the variable, but I have a better question to solve this. What would change the table address shown when printing the table as a whole?
I've been doing some random testing with tables with the following code and found that when you declare a table with another table it does not copy the table to the new variable but the memory address to the table.

a = {1,2,3,4,5}
b = {6,7,8,9,0}
c = {}
setmetatable(c, {
  __index = {a,b},
})
function g (h)
  print(tostring(h))
end
print(tostring(a))
g(a)

so if I did "k=a" and edit the values in "a" it would show up kn "k", because when I do the print on "a" and "k" it shows the same semi-random string following "table: "

Termanater13, on 18 March 2014 - 08:12 PM said:

What would change the table address shown when printing the table as a whole?
I've been doing some random testing with tables with the following code and found that when you declare a table with another table it does not copy the table to the new variable but the memory address to the table.
so if I did "k=a" and edit the values in "a" it would show up kn "k", because when I do the print on "a" and "k" it shows the same semi-random string following "table: "

That would be the behavior i was talking about

CometWolf, on 18 March 2014 - 07:21 PM said:

Unike most other variables, tables will still point to the same adress. This means any changes to the table will be visible from both inside and outside the api at the same time.

only way to around this is to create a copy of the table.