Exactly what I was trying to say, local should be done away with, everything should be local as default and if you want something to be Global then declare it as such. It wouldn’t help us now but it sure would help a lot of newbies from making mistakes.
Very interesting Hendrix, thanks for the debugging tip.
Happy coding.
it can be as easy as adding one more variable in build settings like
reverseGlobalsLocals =
{
– Include only the necessary icon files on each platform
announceGlobals = true
},
meaning that for those that got older projects they can still keep their projects without editing billions of lines, and new people get the option of using the global instead of local like it is now
Can you elaborate more on this, I find it intriguing, never heard of this, “announceGlobals = true”???
Is there any more knowledge you have about the build settings that could save us all a lot more work?
I appreciate your input!
Martin.
settings = { orientation = { -- Supported values for orientation: -- portrait, portraitUpsideDown, landscapeLeft, landscapeRight default = "portrait", supported = { "portrait", "portraitUpsideDown" }, --"landscapeLeft", "landscapeRight", },
sry seems i didn’t write it well enough, i was just giving idea to developers how they COULD implement it easily so that both the old and new developers can keep either local variableName style or global variableName by switching them with a setting inside build.settings
announceGlobals does not exist as such and was given as an example so sorry for miseading you and giving false hope 
I couldn’t agree more.
Am I the only one who thinks that declaring everything local seems like a pointless exercise?
There is a lot of silence coming from the Corona team on this subject, would it be a huge undertaking to fix this issue?
I eagerly await responses…
Yes, huge, google it, long-debated – easier to stop thinking its broke, because then it doesn’t need to be fixed. ;)
Local-by-default only sounds “better” until you do some functional -style programming, and try to reference a nested outer scope – that is, something not local, yet not global either – then you’d see how confounding it would be to access those “middle” scopes.
“external local variables” or upvalues. Yes there are some subtleties in this matter
In other languages it is like you say QuizMaster, default to locals unless you declare it as global
Interesting reading here:
@Dave, yes that makes perfect sense but I’m not talking about functions here, we all know that something inside a function is local to that function unless you declare the variable local outside of it.
I’m talking about everything else, looking through my code it’s local this, local that, local, local local… seems crazy.
@Hendrix, yes I read that when I first started learning LUA to get a grasp in the language to help me with Corona, I found it very confusing, thank god Corona is a lot easier to understand.
I bet this is a bigger subject than I originally thought it was, I’m going to do some reading and learning.
Happy coding everyone.
I agree to that QuizMaster
Many potential issues tends to solve themselves if we just forward declare the locals in the start of the code due to lexical scoping 
What a great post. I really, really should have read this before I started my app, but live and learn.
Do all transitions and timers leak memory if they are not explicitly tracked?
I am under the impression, that they do. Currently every scene with transition has to have a _transition = {} table to keep all my transition references. Same with _timers = {}. In libraries and a lot of code I see, people don’t seem to track them.
They should not…
Rob
Here’s my experience of timers and transitions…
It’s not memory leaks that you should be concerned with as long as you cancel all the timers and transitions.
You have to be wary of them still running when moving onto a different scene though.
Just because you nil a timer or transition doesn’t mean it can’t be created again by another timer or transition, you have to be diligent.
> It’s not memory leaks that you should be concerned with as long as you cancel all the timers and transitions.
See, it’s that kind of statement that leads me to a conclusion.
If I don’t capture the timers and transitions, how can I cancel them on destruction?
If I have to capture them all, to explicitly destroy, then they are inherently leaky.
That’s not what I’m saying.
I’m just pointing out that if you don’t cancel all your timers and transitions before you move onto your next scene you could run into problems. If your previous scene only has a couple timers then they are easy to track.
But what if you have a more complex scene with many many timers and transitions, then you might not know when they all finish doing their job, some could be triggered by other timers, it’s all about making sure everything is stopped before you move on to your next scene and claiming the memory back by nilling them so you don’t get memory creep.
For example, shipTransition = transition.to (spaceShip, {time = 2000, x = x + 1000, onComplete = doSomething} )
After 2 seconds the function doSomething is called, the function doSomething could have more timers and transitions in it, the shipTransition maybe called via a timer or another transition over and over and so and so on and that’s just one simple part of the code. What if you’ve got lots of spaceships and aliens?
You have to track all your timers and transitions otherwise you’ll end up in a right mess, it’s got nothing to do with memory leaks.
First of all, you’ve not proven you have a leak. You have proven you are using memory. Those are two different things. All apps use memory. Memory can grow as the app does more and more things. Leaks are when you repeat the same code (i.e. spawn objects over and over, but don’t increase the number of objects), or repeat scenes over and over and memory keeps growning when it shouldn’t.
Also we don’t know what scale your memory is listed as. If it’s really “bytes”, 600 is nothing. Even if it were 600 K (thousand, well 1024 = 1K) bytes, that’s still nothing in the scale of the device.
You may be fretting over nothing.
Rob
Hi,
I’m repeating the same scenario over and over and the system memory increments 1Kb on each scene changes. If I comment the timer/transition everything is OK.
I’m clear the handle of both timer/transition. What is going on?
Thanks
You’re gaining 1k on each scene change? You’ve got nothing to worry about then.
What you should be worried about is using “module (…, package.seeall)”
It is necessary to do that? Why?