is declaring Corona sdk apis(composer, physics) as Global Variable bad?

every .lua file i write require line like :

local composer = require “composer”

local physics = require “physics”

local widget = require “widget”

…etc

then actually I realize that I can register them as Global Variable.:

initializing .lua file

composer = require “composer”

…other .lua file

print(_G.composer) --okay

is declaring those apis as Global Variable okay?

Hello @thddygks33 and welcome to the Forums!

This is a great question. Generally avoiding globals is a good thing. While making system API’s global is probably okay after all, the rest of the Lua library is as well as our display library.

Note, that the globals table (_G) is the slowest place to look up items, so if you’re going to be doing physics.addBody() or object:applyLinearImpulse() in a tight loop or in enterFrame listeners, you may take a performance hit.

Because globals are bad in many ways, in particular for poorly scoped variables and work arounds to avoid scoping, we generally recommend avoiding them until you understand when globals are helpful vs. when they are a convenience. Typing a couple of lines a few extra times is worth saving you from the downsides of globals.  Hopefully you are using the Composer scene template as your starting point for your Composer scenes, and if so you could drop those require’s in the template and have them done already for you.

Rob

thank you for answer! it’s very helpful!

I should have said “poorly named variables” above, but I think it works our to be the same reason.

For anyone finding this thread: A variable named “i” is the worst possible global variable name or is something like player, target, event. Those names get used a lot and their meaning is usually very specific to the location they are being used. As you move from local to app-wide in scope, variable and function names need to become more specific such as menuSceneBackButton. Global variables need the best “name spaced” (i.e. most specific) names to minmize the chance that some other code is trying to use the same variable name.

Rob

Hello @thddygks33 and welcome to the Forums!

This is a great question. Generally avoiding globals is a good thing. While making system API’s global is probably okay after all, the rest of the Lua library is as well as our display library.

Note, that the globals table (_G) is the slowest place to look up items, so if you’re going to be doing physics.addBody() or object:applyLinearImpulse() in a tight loop or in enterFrame listeners, you may take a performance hit.

Because globals are bad in many ways, in particular for poorly scoped variables and work arounds to avoid scoping, we generally recommend avoiding them until you understand when globals are helpful vs. when they are a convenience. Typing a couple of lines a few extra times is worth saving you from the downsides of globals.  Hopefully you are using the Composer scene template as your starting point for your Composer scenes, and if so you could drop those require’s in the template and have them done already for you.

Rob

thank you for answer! it’s very helpful!

I should have said “poorly named variables” above, but I think it works our to be the same reason.

For anyone finding this thread: A variable named “i” is the worst possible global variable name or is something like player, target, event. Those names get used a lot and their meaning is usually very specific to the location they are being used. As you move from local to app-wide in scope, variable and function names need to become more specific such as menuSceneBackButton. Global variables need the best “name spaced” (i.e. most specific) names to minmize the chance that some other code is trying to use the same variable name.

Rob