This may be a time saver for some people.

Solar2D General Questions/Discussion
#1

If you are always defining variables/functions at the top of the script to make it quicker to write then this may be good for you.
 
You can store all of the variables in a module and return a specific function to set your enviroment to the variables when called
 
Module -> Variables.lua

-- Required to be defined globaly centerX = display.contentCenterX centerY = display.contentCenterY actualW = display.actualContentWidth actualH = display.actualContentHeight originX = display.screenOriginX originY = display.screenOriginY return function() setfenv(2, getfenv()) end

Script

require('Variables')() -- should always be on the first line or it will wipe out all variables above it print(actualW,actualH)

This could also be used to make your code look cleaner.

Note: If you are using an editor with a syntax highligher this may not be good as it triggers it to think it’s undefined.

#2

Hey Lua,

this sounds great.

One question, if you define the variables globally (which is mandatory you say), are they still accesed globally in the document you require them, or does setfenv “localizes” them?

Other thing which might be a downside is, that you still use global namespace, as these variables are defined globally in the first place, am I right?

Regardless, I will try it out as it sound great :slight_smile:

#3

Since they are defined as globals, you shouldn’t need to do any of the function call stuff.

This would work just as well:

Module -> Variables.lua

-- Required to be defined globaly centerX = display.contentCenterX centerY = display.contentCenterY actualW = display.actualContentWidth actualH = display.actualContentHeight originX = display.screenOriginX originY = display.screenOriginY

Script

require('Variables') --no longer any need for extra () print(actualW,actualH)

However since this is just a way of creating lots of global variables, the only advantage I can see is that you can move it to its own file for the sake of tidiness. 

I don’t like using globals at all if I can help it, so I tend to put all my “globals” into a table and require that table in each class I use:

Module -> globals.lua

local globals = { centerX = display.contentCenterX, centerY = display.contentCenterY, actualW = display.actualContentWidth, actualH = display.actualContentHeight, originX = display.screenOriginX, originY = display.screenOriginY, } return globals

Script:

local globals = require("globals") print(globals.actualW, globals.actualH)

Not only does it remove lots of genuine globals from my code, but it’s also very easy for me to look at a variable and know for sure that it’s something that I’m using as globally (even though it actually belongs to a localised table).  

I have the require at the top of almost every script I write, which may be slightly redundant but allows me to completely get rid of “real globals” while still having some variables that can be accessed in multiple files.

#4

I tested a bit with the initial example and I don’t see the benefit here.

As pointed out, you are still using the global name space and global variables, so what is the point in setting the function enviroment? (which works with globals in general as I understand it)

@Alan

That’s what I do too most of the time. But to save performance and shorten the variable name length, I find myself localizing the values I use most of the time, which brings us to the start of the whole problem. (to clarify, using variables.variable1 is longer than simply variable1 and it uses more performance, as a table lookup is involved)

So it would be great, if you could just “copy” local variables from one file into another with a single function call, but I think that’s impossible, considering the concept of a dynamic language and the concept of scope.

#5

Yes I agree. I suppose you could use get and set functions, but again that just adds overhead. In all honesty the main advantage for me using a table is the one I mentioned earlier, which is being able to know for sure that the variable is being used as a global. 

i.e. 

variable1  - could be global or local, would need to find the first place it’s defined to know for sure.

globals.variable1 - I know for sure this belongs to my table of globals.

I know some people explicitly use the _G. table when naming global variables, but I’ve never liked doing that.

#6

I took a deeper look into the matter and it seems like setfenv and getfenv are sandboxing methodes, that are mainly used for debugging.

So I’m not sure if it’s a good idea to use them everywhere, especially as they where replaced in the lastest LUA verions (5.2) because of security concerns.

Anyways, I tested them a bit and here’s what the function does in my understanding:

It simply set the global enviroment for funtion or a complete module. This global enviroment can be defined via a table which contains values or as shown in the initial example, by creating global variables.

Inside the function or module you set the enivroment for, only global variables from the enviroment might be used, all other (even the standard ones like print, pairs, math etc. are undefined).

This underlines the statement of enviroments beeing only for testing purpose. (some compilers even remove them, as they just see them as insecure testing stuff)

Maybe somebody has deeper insights or can correct me? Would be great to learn more :slight_smile:

#7

Hey Lua,

this sounds great.

One question, if you define the variables globally (which is mandatory you say), are they still accesed globally in the document you require them, or does setfenv “localizes” them?

Other thing which might be a downside is, that you still use global namespace, as these variables are defined globally in the first place, am I right?

Regardless, I will try it out as it sound great :slight_smile:

#8

Since they are defined as globals, you shouldn’t need to do any of the function call stuff.

This would work just as well:

Module -> Variables.lua

-- Required to be defined globaly centerX = display.contentCenterX centerY = display.contentCenterY actualW = display.actualContentWidth actualH = display.actualContentHeight originX = display.screenOriginX originY = display.screenOriginY

Script

require('Variables') --no longer any need for extra () print(actualW,actualH)

However since this is just a way of creating lots of global variables, the only advantage I can see is that you can move it to its own file for the sake of tidiness. 

I don’t like using globals at all if I can help it, so I tend to put all my “globals” into a table and require that table in each class I use:

Module -> globals.lua

local globals = { centerX = display.contentCenterX, centerY = display.contentCenterY, actualW = display.actualContentWidth, actualH = display.actualContentHeight, originX = display.screenOriginX, originY = display.screenOriginY, } return globals

Script:

local globals = require("globals") print(globals.actualW, globals.actualH)

Not only does it remove lots of genuine globals from my code, but it’s also very easy for me to look at a variable and know for sure that it’s something that I’m using as globally (even though it actually belongs to a localised table).  

I have the require at the top of almost every script I write, which may be slightly redundant but allows me to completely get rid of “real globals” while still having some variables that can be accessed in multiple files.

#9

I tested a bit with the initial example and I don’t see the benefit here.

As pointed out, you are still using the global name space and global variables, so what is the point in setting the function enviroment? (which works with globals in general as I understand it)

@Alan

That’s what I do too most of the time. But to save performance and shorten the variable name length, I find myself localizing the values I use most of the time, which brings us to the start of the whole problem. (to clarify, using variables.variable1 is longer than simply variable1 and it uses more performance, as a table lookup is involved)

So it would be great, if you could just “copy” local variables from one file into another with a single function call, but I think that’s impossible, considering the concept of a dynamic language and the concept of scope.

#10

Yes I agree. I suppose you could use get and set functions, but again that just adds overhead. In all honesty the main advantage for me using a table is the one I mentioned earlier, which is being able to know for sure that the variable is being used as a global. 

i.e. 

variable1  - could be global or local, would need to find the first place it’s defined to know for sure.

globals.variable1 - I know for sure this belongs to my table of globals.

I know some people explicitly use the _G. table when naming global variables, but I’ve never liked doing that.

#11

I took a deeper look into the matter and it seems like setfenv and getfenv are sandboxing methodes, that are mainly used for debugging.

So I’m not sure if it’s a good idea to use them everywhere, especially as they where replaced in the lastest LUA verions (5.2) because of security concerns.

Anyways, I tested them a bit and here’s what the function does in my understanding:

It simply set the global enviroment for funtion or a complete module. This global enviroment can be defined via a table which contains values or as shown in the initial example, by creating global variables.

Inside the function or module you set the enivroment for, only global variables from the enviroment might be used, all other (even the standard ones like print, pairs, math etc. are undefined).

This underlines the statement of enviroments beeing only for testing purpose. (some compilers even remove them, as they just see them as insecure testing stuff)

Maybe somebody has deeper insights or can correct me? Would be great to learn more :slight_smile: