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. (I never did like having those single lines of code (aka "global TestVar") living outside of any handler in my scripts. They were - if I may use the past tense - an ugly feature of the language too...) ~ Chris Innanen ~ Nonsanity On Thu, Jul 7, 2011 at 11:01 AM, Richard Gaskin <ambassa...@fourthworld.com>wrote: > Francis Nugent Dixon wrote: > > I think Scott has the right attitude. Use globals >> if you need them, Use custom properties if you don't >> like the power/scope/limitations of globals. >> > > I would respectfully amend that to read: > > Use globals if you need them, use custom properties if you need data bound > persistently to an object, and use accessors for anything else. > > Variables are volatile (they go away when the session ends), and that's a > very useful feature in many cases. Binding data to objects can cause those > values to remain with the object if the object is in a stack that gets > saved. If you need values to persist between sessions then properties may > be the best choice, but if you need volatility globals or accessors that use > globals can be a better fit. > > -- > 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<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<http://lists.runrev.com/mailman/listinfo/use-livecode> > _______________________________________________ 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
