When to Localizing, modules and tables?

Solar2D Lua Language
#1

Hey guys,

I’m doing alot of reading about lua and corona tutorials. One thing I see very often is developers not localizing their code to the files. Here’s a few things I’ve seen…

require("someModule")-- this is how I've learned itlocal someModule = require("someModule")

Another thing I’ve seen and not really seen any explanation to is…

someLuaFile.lua

return { someVar = 1234, anotherVar = "varName" }

While I know that does the same thing as…
someLuaFile.lua

local t = { someVar = 1234, anotherVar = "varName"}return t

I know the purpose of this but what benefits do I get from either one, what is best and when should I use one over the other?

Thanks

#2

Localisation makes lua faster, even about 30% faster. It is the best for modules and frequently used libs or functions.

However, there is always something called “premature optimalization”. This is in case of someLuaFile.lua. In both cases you return the same table but in second case you add aditional step of assigning table to variable (useless step). There is nothing wrong with 

return { someVar = 1234, anotherVar = "varName" }

Because you create table and return it instead of create>assign>return.

#3

So what you’re saying is I could possibly save a few “micro” seconds on returning the table right away?

#4

Yes, the best optimalization is “do not do it” :P. It would save just few code instructions so I think it doesn’t make difference at all.

#5

I just think it makes the code more readable when going that extra step.

But what about when we use the “OOP” way that most have started doing…

[lua]
local M = {}

function M:doSomething()

end

return M

[/lua]

Could we do this then…

[lua]
return {
doSomething = function()

end,

doAnotherThing = function()

doSomething()

end
}
[/lua]

#6

Read about “premature optimatization”. If one method is good for one thing then it doesn’t automaticaly mean you should use it everywhere you can - it’s bad practice. Good programmer is not the one that knows about everything but one who knows if and when to use something.

If you have short return then there is no need to create local in one line and destory in another (because you leave function then function’s local are deleted). However if you have big functions or such then it’s better to split things to make reading code easier.

#7

this is very poor programming practice:

require("someModule")

in order to work, it requires that the module either inject global variables in the application or over-write an existing object’s parameters or functions ; generally an object that the module /doesn’t/ own (eg, ‘display’ or ‘Runtime’ or …).

coding using either of these methods creates fragile code and opens yourself to hard-to-find bugs or future misery when something changes. why make your programming effort more challenging than it already is ? =)

do this and be happy (and leave out globals / object hijacking):

local someModule = require("someModule")
#8

Just a reflection… When returning a table directly ( return{ } ), does that make the table global or local?

#9

Theoretically none of that, because this is just funtion prototype. All matters is what will you do with this table. Let’s say you have
[lua]
local function createTable()
return {}
end
[/lua]

If you do
[lua]
local t = createTable()
createTable()
[/lua]
Then first line will create local variable and second one will create global (however it should be garbage collected in some time)

#10

Localisation makes lua faster, even about 30% faster. It is the best for modules and frequently used libs or functions.

However, there is always something called “premature optimalization”. This is in case of someLuaFile.lua. In both cases you return the same table but in second case you add aditional step of assigning table to variable (useless step). There is nothing wrong with 

return { someVar = 1234, anotherVar = "varName" }

Because you create table and return it instead of create>assign>return.

#11

So what you’re saying is I could possibly save a few “micro” seconds on returning the table right away?

#12

Yes, the best optimalization is “do not do it” :P. It would save just few code instructions so I think it doesn’t make difference at all.

#13

I just think it makes the code more readable when going that extra step.

But what about when we use the “OOP” way that most have started doing…

[lua]
local M = {}

function M:doSomething()

end

return M

[/lua]

Could we do this then…

[lua]
return {
doSomething = function()

end,

doAnotherThing = function()

doSomething()

end
}
[/lua]

#14

Read about “premature optimatization”. If one method is good for one thing then it doesn’t automaticaly mean you should use it everywhere you can - it’s bad practice. Good programmer is not the one that knows about everything but one who knows if and when to use something.

If you have short return then there is no need to create local in one line and destory in another (because you leave function then function’s local are deleted). However if you have big functions or such then it’s better to split things to make reading code easier.

#15

this is very poor programming practice:

require("someModule")

in order to work, it requires that the module either inject global variables in the application or over-write an existing object’s parameters or functions ; generally an object that the module /doesn’t/ own (eg, ‘display’ or ‘Runtime’ or …).

coding using either of these methods creates fragile code and opens yourself to hard-to-find bugs or future misery when something changes. why make your programming effort more challenging than it already is ? =)

do this and be happy (and leave out globals / object hijacking):

local someModule = require("someModule")
#16

Just a reflection… When returning a table directly ( return{ } ), does that make the table global or local?

#17

Theoretically none of that, because this is just funtion prototype. All matters is what will you do with this table. Let’s say you have
[lua]
local function createTable()
return {}
end
[/lua]

If you do
[lua]
local t = createTable()
createTable()
[/lua]
Then first line will create local variable and second one will create global (however it should be garbage collected in some time)