Nonsanity wrote:
I actually prefer to use custom properties even for values that I want to be
session-specific. The reason being that I'd rather have personal control
over when the value is cleared than leave it to the environment to handle.
This way I can be sure I know the contents of the variable (as a custom
property) at all times. It never gets changed out from under me, and so will
never surprise me or my code.
With globals, you need to handle the case of an empty (unset) value
everywhere the global is used, or you need to initialize the global to a
starting value at startup - The place where it will get emptied at the start
of each session.
Using a custom property, if you need the value to be reset to a particular
value on startup you do it yourself in the OpenCard or PreOpenCard. If you
want it to be emptied like a global, you can do that there too. But at least
you have all the control yourself. No more surprises.
I really only use globals when I'm doing a quick hack script for debugging
purposes, but even there my old Hypercard habits (where globals were the
only option) are being replaced with custom properties.
I really do think of custom properties as the complete replacement, in all
ways, for globals.
Respectfully, those issues and solutions seem to work both ways. For
example, you can set the value of a global on preOpenCard just as easily
as you can set the value of a property, and any script from anywhere can
alter a property just as easily as it can alter a global.
For myself, in addition to the persistence issue (I'm a compulsive
saver) it comes down to simply laziness - I'd rather write:
SetDefaultWidgetHeight 200
...than:
set the uDefaultWidgetHeight of button "someButton" \
of card "someCard" of stack "someStack" to 200
Where properties are unbeatable is when you need to bind data to a
specific object. If you have multiple objects in which each need a
different value, implementing those as properties is the with-the-grain
solution.
But if you need something that's global in scope, I see no harm in using
globals.
From time to time I come across recommendations that globals are
somehow bad practice, yet almost every language supports them so I'm
inclined to think they have a place among our options for value storage.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
