Various Nooby Questions

Getting Started Newbie Questions
#1

Hello!  I’ve been developing in Corona for a little bit but still have a few questions.

1.  If you define a local variable at the very beginning of your code, isn’t that sort of a global variable since it can apply to all functions within that .lua file?  How does declaring it locally there help?  Does it have to do with memory leakage?

2.  I’ve noticed that I can define a characteristic (I don’t know the proper terminology) for a display object.  For example, I can have bubble.xvelocity even though that xvelocity isn’t an intrinsic property of any display object.  However, when I try to access this in a different function after having passed bubble into that function, I fail to be able to access it.  Should I be able to access it or should only the intrinsic properties of display objects be able to be accessed?

Thanks!

#2

To your first question local variables that you declare at the beginning of your code can be seen and used by any method(function) within the class(I mean .lua file sorry been doing java a lot lately).Global variables can be used by all .lua files and their functions and generally are not safe. example if you are a more visual learner

main.lua --> local bubble --> methods in main.lua can use the “bubble” variable but score.lua methods can’t

score.lua  --> “uh oh” I have no variables :frowning:

As to your second question it’s hard to tell exactly what your problem is. Maybe post the error you’re receiving. Otherwise we’re just guessing could be a nil value could be anything.

#3

Awesome, what are some of the bad things that happen with globals?  I figured out what was happening with question two, you can use event.target.attribute.

#4

Bullet point numbers 2 and 4 are the main problems when your program is large. BUT  sometimes globals are necessary when you need one class to be able to change values (talk to another) class. Just don’t make a habit of making a ton of global variables. B)

  • Non-locality  – Source code is easiest to understand when the scope of its individual elements are limited. Global variables can be read or modified by any part of the program, making it difficult to remember or reason about every possible use.
  • No Access Control or Constraint Checking  – A global variable can be get or set by any part of the program, and any rules regarding its use can be easily broken or forgotten. (In other words, get/set accessors are generally preferable over direct data access, and this is even more so for global data.) By extension, the lack of access control greatly hinders achieving security in situations where you may wish to run untrusted code (such as working with 3rd party plugins).
  • Concurrency issues  – if globals can be accessed by multiple threads of execution, synchronization is necessary (and too-often neglected). When dynamically linking modules with globals, the composed system might not be thread-safe even if the two independent modules tested in dozens of different contexts were safe.
  • Namespace pollution  – Global names are available everywhere. You may unknowingly end up using a global when you think you are using a local (by misspelling or forgetting to declare the local) or vice versa. Also, if you ever have to link together modules that have the same global variable names, if you are lucky, you will get linking errors. If you are unlucky, the linker will simply treat all uses of the same name as the same object.
#5

Also, albeit possibly a minor issue, globals are slower to be accessed then locals.

#6

To your first question local variables that you declare at the beginning of your code can be seen and used by any method(function) within the class(I mean .lua file sorry been doing java a lot lately).Global variables can be used by all .lua files and their functions and generally are not safe. example if you are a more visual learner

main.lua --> local bubble --> methods in main.lua can use the “bubble” variable but score.lua methods can’t

score.lua  --> “uh oh” I have no variables :frowning:

As to your second question it’s hard to tell exactly what your problem is. Maybe post the error you’re receiving. Otherwise we’re just guessing could be a nil value could be anything.

#7

Awesome, what are some of the bad things that happen with globals?  I figured out what was happening with question two, you can use event.target.attribute.

#8

Bullet point numbers 2 and 4 are the main problems when your program is large. BUT  sometimes globals are necessary when you need one class to be able to change values (talk to another) class. Just don’t make a habit of making a ton of global variables. B)

  • Non-locality  – Source code is easiest to understand when the scope of its individual elements are limited. Global variables can be read or modified by any part of the program, making it difficult to remember or reason about every possible use.
  • No Access Control or Constraint Checking  – A global variable can be get or set by any part of the program, and any rules regarding its use can be easily broken or forgotten. (In other words, get/set accessors are generally preferable over direct data access, and this is even more so for global data.) By extension, the lack of access control greatly hinders achieving security in situations where you may wish to run untrusted code (such as working with 3rd party plugins).
  • Concurrency issues  – if globals can be accessed by multiple threads of execution, synchronization is necessary (and too-often neglected). When dynamically linking modules with globals, the composed system might not be thread-safe even if the two independent modules tested in dozens of different contexts were safe.
  • Namespace pollution  – Global names are available everywhere. You may unknowingly end up using a global when you think you are using a local (by misspelling or forgetting to declare the local) or vice versa. Also, if you ever have to link together modules that have the same global variable names, if you are lucky, you will get linking errors. If you are unlucky, the linker will simply treat all uses of the same name as the same object.
#9

Also, albeit possibly a minor issue, globals are slower to be accessed then locals.