Page 53 of 91
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Mar 05, 2016 3:12 am
by Foogles
If I have a table:
Code: Select all
table = {}
table.number
table.body
table.shape
table.fixture
And then I do
Would that store a reference to the table or duplicate it?
I'm also trying not to dwell on the paradoxical implication that it will create a copy of the fixture in the data for the fixture.
EDIT: I just realized I can do...
Code: Select all
local info = {type = "bullet", index = i}
table.fixture:setUserData(info)
Which should work really well and be more friendly to my code.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Mar 05, 2016 3:22 am
by s-ol
There is no such thing as copying a table really. Tables are always passed around like what in other languages is called "by reference" and primitive type variables behave like "passing by value". set/getUserdata associates that same exact table with the fixture. And löve won't go into a four dimensional time hole loop cycle and consume your PC.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Mar 05, 2016 3:36 am
by Foogles
S0lll0s wrote:There is no such thing as copying a table really. [...] And löve won't go into a four dimensional time hole loop cycle and consume your PC.
Thank you very much for your time and information. I am relieved to hear that löve isn't going to break the space time continuum, as I probably wouldn't have slept well tonight otherwise.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Mar 05, 2016 6:55 am
by Davidobot
Foogles wrote:S0lll0s wrote:There is no such thing as copying a table really. [...] And löve won't go into a four dimensional time hole loop cycle and consume your PC.
Thank you very much for your time and information. I am relieved to hear that löve isn't going to break the space time continuum, as I probably wouldn't have slept well tonight otherwise.
To be fair, if you want to copy a table, you can:
http://lua-users.org/wiki/CopyTable
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Mar 05, 2016 2:42 pm
by s-ol
The thing about "copying a table" is that it is very ambiguous term
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Mar 05, 2016 5:20 pm
by Davidobot
S0lll0s wrote:
The thing about "copying a table" is that it is very ambiguous term
Well, defining "copying" yields this: "a thing made to be similar or identical to another."
So the above link provides a method of creating a separate (not a pointer) table variable that is exactly identical to the original one.
Re: "Questions that don't deserve their own thread" thread
Posted: Sat Mar 05, 2016 5:28 pm
by s-ol
Davidobot wrote:S0lll0s wrote:
The thing about "copying a table" is that it is very ambiguous term
Well, defining "copying" yields this: "a thing made to be similar or identical to another."
So the above link provides a method of creating a separate (not a pointer) table variable that is exactly identical to the original one.
Thats still very ambigious, is a table copy supposed to be deep or a shallow copy, and if deep, what happens to userdata? Are metatables set? Are metatables duped too?
Of course you can write a function for one variant of copying but there is no fits all way to "copy a table".
Btw this is an issue in JS for example aswell, the most common way to duplicate a JS object is to do JSON.decode(JSON.stringify(object)) afaik. And that's only useful if the data is a " data object" kind of thing (just primitive types and objects of primitive types)
Re: "Questions that don't deserve their own thread" thread
Posted: Sun Mar 06, 2016 7:22 am
by Davidobot
S0lll0s wrote:
Thats still very ambigious, is a table copy supposed to be deep or a shallow copy, and if deep, what happens to userdata? Are metatables set? Are metatables duped too?
Of course you can write a function for one variant of copying but there is no fits all way to "copy a table".
Btw this is an issue in JS for example aswell, the most common way to duplicate a JS object is to do JSON.decode(JSON.stringify(object)) afaik. And that's only useful if the data is a " data object" kind of thing (just primitive types and objects of primitive types)
That link has both a deep copy (copies metatables, I'm not sure about userdata though) and a shallow copy.
Re: "Questions that don't deserve their own thread" thread
Posted: Tue Mar 08, 2016 4:12 pm
by PrussianBlue
I am trying to create a function that takes an arbitrary amount of variables, like so:
Code: Select all
function GameInterface:passInputThroughStack(handler_function, ...)
and I want to call the variables within the function using unpack(arg). The issue is - arg seems to be used by the engine itself, it's a table with the program execution path, so a string like "C:\Users\Username\Desktop\Love\Project", and seems to be set from the first line of love.run onwards. I can't get it to accept the arguments from ... instead.
I am using the default love.run, and version 0.9.2.
Apologies if the question has already been answered, the forum search discards the keyword arg.
Re: "Questions that don't deserve their own thread" thread
Posted: Tue Mar 08, 2016 5:00 pm
by slime
'arg' as an alias for varargs was deprecated in Lua 5.1 (sadly the official online version of the Programming in Lua book is still the first edition for Lua 5.0, which was superseded in 2006). You can just use "..." directly, for example:
Code: Select all
function GameInterface:passInputThroughStack(handler_function, ...)
print(...)
for i=1, select("#", ...) do
local v = select(i, ...)
dothing(v)
end
local a, b, c = ...
local args = {...}
assert(args[2] == b)
end