Hello Scott, Ok, what I can follow is the better reference and with that the better documentation "to whom an information belongs" with properties instead of globals, as far there is a connection between them (not to store the number of legs of the cat independ of the cat in a global). So I see an advantage in style, but not in safty against unwilling change. For statuses and flags (user has done something or not / a handler or condition was called, or not,...) I don't have a relation to any object, so I would prefer globals. Can you go with this? Thank you for your thoughts Tiemo
-----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Scott Kane Gesendet: Freitag, 22. Juni 2007 12:20 An: How to use Revolution Betreff: Re: Best Practices using globals vs. custprops? From: "Tiemo Hollmann TB" <[EMAIL PROTECTED]> > on various sites - and again in this best practice thread - it is > recommended not to use globals, or at least so less as possible, because > they can be changed from everywhere and that's hard to debug and no nice > style. I really don't see any difference between using globals or > properties > yet. Properties can be changed also "from everywhere" and even if you > write a central handler to change your properties, this handler can be > called from > everywhere. What is the best practice for statuses, flags and all these > global informations, you need at different times and in different > handlers? > And if there is a "clean pratice", what is the difference to using > globals? Globals are a kind of variable. As you note it's considered best practice in most programming languages to avoid using them unless absolutely necessary. However they can come in handy for some things. Generally a local variable is safer because it's scope is within the procedure (in Rev the on statement) or function. Limiting scope to local limits the chance of accidentlal results (or undesirable or unpredicted results). I'd not recommend somebody new to programming to use globals at all until they've had some experience debugging and understanding scope. Properties need to be thought of as pieces of an object. For example. A Cat. A Cat has legs. Legs are properties of cats. Cats pretty much have four legs (barring a major accident for the moggy) so it's safe to assume there will always be four legs (properties) of a Cat. This is just like a button object. The button always, for example, a label property unless we create a button that does not (which is no mean feat in a technically non object orientated language like Rev which doesn't allow decendent classes like some other languages - in the strictest sense of the word). So the Label is always there and we know we can stick in some text into myButton or into theOtherButton and we are safe. Quite distinct to a variable which is declared in our code (locally or globally). Variables don't have properties. Flags... Not sure what you mean here...? Best practice is to comment your code. Just because you know what your variable does today doesn't mean you will tomorrow or next year (or ten years from now). So comment, comment and comment. This is critical with globals. Name your local variables in a manner that *you* can easily see at a glance that they are local variables and if you absolutely have to use a global make sure you lable it clearly to and document it so that you don't use the name somewhere else and potentially cause problems for yourself. I'd recommend taking a look at how these things are done in some of the example stack available on RevOnline. Many of these are exemplar and worthy of perusal. Scott Kane _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
