On Oct 12, 2012, at 9:13 PM, J. Landman Gay wrote:
> On 10/12/12 6:50 PM, Timothy Miller wrote:
>>
>> I consistently put empty into all unused globals when a script starts.
>
> Unlike HyperCard, in LiveCode you can actually delete them entirely:
>
> delete global gMyGlobal
>
> I don't have a particular hatred for globals either, you just have to know
> how to be careful with them. On the other hand, I don't think I've needed one
> now for years but if I did, I wouldn't hesitate to use it. They are faster
> and more convenient than a property or a handler, but their main advantage is
> that they aren't tied to any particular stack. That's a big advantage, even
> if you don't need it very often.
Agreed - I use globals, but give them unique names to avoid kaboshing anyone
else's globals (like "gSTS_FillInTheBlank"). To *me* the main downside with
them is that you have to declare them in any script that wants to use them… so
they're not *truly* global until you set up a connection to them. Personally
I'd find globals more useful if once declared and set that they didn't need to
be declared again to be used, but if that were to happen, I'd probably want to
see Bob's suggestion (applicaton globals vs. stack globals) or the equivalent
put into place to apply a scope to them.
But all the options have their pros and cons:
Globals:
Pros: Easy to use, available everywhere, resides only in memory (so
they're disposed of as soon as the engine quits); can be multidimensional
arrays (which can cut down on the number of actual globals you use, BTW)
Cons: Easy to kabosh if not careful, you need to declare them in every
script that uses them
Functions:
Pros: Only need to be created once at design time and can be called
from everywhere that has access; more flexibility (it can take parameters to
adjust the returned value so you could simulate multiple dimensions by using
parameters)
Cons: The function needs to be in the available message path, which
means that you'd need to use a frontscript/backscript/library to make it
available to more than a single mainstack (and if you *do* that, you need to be
careful of naming conventions because someone else might kabosh your function
name); the actual data that is returned has to be stored somewhere if it's not
just a calculation (although you can use a script local in the script that has
the function so that it isn't permanently stored anywhere)
Custom Props:
Pros: Is "stuck" to an object (like a stack), so you know the value is
specific to that object (e.g. the uVersion of <stack> vs. gMyStackVersion);
only needs to be created once at design time; can be reached from anywhere so
long as the object it's attached to is available
Cons: *Much* easier to accidentally store permanently what should be a
temporary change to a value (for stacks that need to call "save" for any
reason); more difficult to use (gMyGlobal vs. "the uWidgetType of btn 3 of card
123 of stack 'WhoTheHellCares'")
I'm sure there's more, but those are what popped into my head. :D
Ken Ray
Sons of Thunder Software, Inc.
Email: k...@sonsothunder.com
Web Site: http://www.sonsothunder.com/
_______________________________________________
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
