This content has been marked as final. Show 7 replies
Personally, I have never agreed with the assertion that globals are bad.
I use them in every project and see no reason to stop. There are some
folks who believe the Object Oriented code is superior to standard
coding, and to a degree I can go along with it. If most of the running
code is taking place inside a parent script, then there is typically
little use in storing globals. But some variables call for global-ness
since it will be used multiple times in multiple places.
The key here is to use the right tool for the right job. If a global
makes your life easier, then go with it. That's my approach at least.
Thanks Mike. I've never used parent scripts. Never really understood them.
I'm really just a beginner in programming.
Is my understanding of property variables and globals in terms of memory
Yes. A global will use a bit more memory since it is always there and a
property will be released when the sprite is no longer showing. But the
thing is that the amount of memory in the variable is typically very
very small. Unless you have a global that stores the text of War and
Peace or something... But if you have a variable like
well, that is not even a noticeable amount of memory. More important
than the pure amount of memory is the code execution. For example if
you need to evaluate some sort of statement to get the value, it takes
some time. If you need to do that evaluation 100 times then it takes
100 times longer (all together). If you only do it once, then store it
in a global and forevermore refer to the global instead of re-evaluating
the statement, then you will have saved a lot of processing time. That
could potentially make your program run faster and more efficiently.
Therefore, I refer to my original statement that you should use the
right tool for the right job. There are times when globals are the most
appropriate way to deal with a situation, and times when they are not.
If it makes your life easier in authoring, or if it makes the playback
run better, then it is foolish to think that you should avoid globals
because someone said they are a bad idea. But you should also consider
using them only when they are most appropriate.
Thanks Mike. You are a great support here. I appreciate your answers even to
questions I don't ask as you give clear and helpful replies.
The difference doesn't have to do with memory requirements for the variable
itself - it's the same for both globals and properties.
Far as ram is concerned, a property will be released soon as the object it
refers it is released, while a global will stay active during the entire
program. So, unless you are storing many large data objects (e.g. image
objects) using either type shouldn't be an issue.
In general, using properties leads to clearer and safer code - imagine
accidentally using the same global variable in two scripts..
The ability to use globals at will is the biggest advantage of single
threaded applications, like director, compared to multithreaded ones, where
you need to lock/unlock everything that is outside the local scope.
However, as a rule, I'd highly suggest not overdoing it with the use of
globals, for the reasons mentioned above - clarity and stability, that is.
If you see a global in your code, you'll know that is supposed to be either
addressed by more than one scripts, or by multiple instances of the same
script (child objects).
Also, it would be good to use a clearglobals command either in a
start/preparemovie or stopmovie handler, so that you don't have issues with
previously initialized globals while restarting playback in authoring mode.
Btw, assuming that director first checks the local scope and then the
global, accessing properties from within an object should be faster than
"student" <email@example.com> wrote in message
>I have read people say that global variables should be avoided as much
> as possible. I use them fairly often and find them very useful. So,
> thought I'd ask for people here to give their views. Why do some people
> suggest globals are bad? From a memory point of view, my understanding
> is that globals are available through an entire movie so are always
> occupying memory. Property variables for a sprite with a behavior that
> has them, are forgotten when you go to another frame without that sprite
> or when you stop a movie. So, I guess they take up less memory because
> of that right? What if you had a sprite that extends the entire length
> of your movie and it has a bunch of properties, is that a lot better
> than just setting up globals that can be accessed over the movie?
> Anything you can offer to explain the pros and cons of using properties
> vs globals would be appreciated.
> Thanks in advance.
Yes, I know to be careful when using globals that I don't overwrite the data in
another script accidentally. I try keep globals for things that will be widely
available across my movie and properties that are only used within one
behavior. And I follow conventions of using a 'g' prefix for global variables
and 'p' or properties so don't mix them up.
Glad to hear there isn't bigger implications of using globals that I may not
have been aware of.
I use objects to organise my code. Since I follow that strategy, my code on larger projects is better organised. It keeps properties that belong together in one place, together with the methods that work on them. If you add new scripts and new movies, you only have to add a few global references.
In my current project, I just keep a few globals, witch are in fact instances of singleton classes with a lot of properties. The globals that I have are objSettings, objPersonalSettings, objLessonData, objResults. Just four of them.
When I instantiate a class I can use the parameter isTest. When set to true, the object initializes its properties with values for testing purposes. In this way I can implement and test all functionality while the implentation of the reading of the settings hasn't been done yet.
I can still acces all my properties globally, I just need to use the reference to the object as well (objSettings.setting1 and objSettings.setting2 come in place of gSetting1 and gSetting2).
So while there is no real fundamental difference with the strategy of using global variables for every property I need, it keeps my code clearer and better organised. The disadvantage is that I have to type more. My biggest frustration about director are the limited capabilities of the script editor. I have worked with Visual Studio and Eclipse, and I have gotten (too much) used to code assist features. If you don't know what that is, it means that the editor shows you all properties and methods of your object after you typed for instance 'objLessonData.' (they appear after you type the period). Current versions of these (and other) editors even know that I am going to type 'objLessonData' after I just typed 'ojbL'. I would love to see something like that in the next release of director, but I believe it wasn't even on the wishlist.
example of script:
on new me, isTest
if not objP( objLessonData ) then
if isTest then
me.initForTest() --initialisation for testing purposes
me.init() --normal initialisation
objLessonData = me --create only a new object when the object doesn't exist yet, singleton pattern
return objLessonData --object already exists, so return reference to it
on initForTest me
on init me
--code to read settings from database or ini-file
--not implemented yet
on doSomethingElse me
--every other method that is meant to work on the properties of
--this script is kept here as well