Field or Global
Monkey Forums/Monkey Programming/Field or Global
| ||
| Any real advantages/disadvantages to creating Fields in your main class (that extends App) rather than declaring Global variables? I've been tending to use Fields, but haven't done anything complex enough to cause an issue, if one is likely to arise. |
| ||
| You usually have a benefit to not use global variables across to many files since that can make your code more complex. It depends on your aim. It is more useful if you are productive than if you write "modular" or "readable" code most of the time. What ever path that creates the results you want is a useful one. To answer your question in more detail it would probably depend on your specific Game - and what you aim to do with it, how big it is and so on. I would say the choice in a productivity one. You might get name-clashes when using globals, but you can always solve those using module name or the Alias keyword. I see no downside to using fields in your App class. Only difference is that to access those fields you need to be in the App class, or have access to the App class object. You only have one App object, and it is created on start and used until the end of the app - so a field therein is just like a global. The most dangerous thing with globals or fields in monkey is that you might by misstake call mojo before OnCreate has been called. If you do this: Global MyClass:TestClass = new TestClass And TestClass contains mojo commands, you get a crash because you use mojo before OnCreate, but it might not look that way :) |
| ||
| Really it makes no difference unles your app is huge. You shouldn't go overboard with globals, but if there are some resources that will be widely accessed, globals may be the simplest approach. One area I find globals useful is, for example: my buttons code contains a number of globals that record standard graphics, font, sound etc. for buttons. They are private but there is a public function to initialise them. Once I have done so, I can just declare a new button with a screen rectangle and text, and it will take the rest from the standard values. Passing this sort of stuff around as parameters would be a pain, and mostly you want all your buttons to look alike. But for less specific items that the above it is less clear and in fact I am leaning towards putting them in the app where they are all in one place. You can then declare a global instance of the App (called theApp say) and anything that wants to can import myapp and read those fields. |
| ||
| " You only have one App object, and it is created on start and used until the end of the app - so a field therein is just like a global " . That's how I've been looking at it...just wanted to catch myself early if I was overlooking something. Thanks. |
| ||
| a very simple rule of thumb: Always fields and locals never globals (if you can avoid it) |
   |