I’ve read the Xojo docs on Modules, and see that we are advised to only sparingly place Global Methods and Global Properties is them. Why only sparingly? What is it about OOP, or Xojo’s OOP in particular, that results in this caution? What could happen if I made extensive use of this? Perhaps house Properties that tell the Project which Customer is the selected one, or which layout – the Desktop Layout WebContainer or the Mobile Layout WebContainer – is the embedded one.
Global modules & global properties lead to “spaghetti code”
Code that is hard to follow and hard to debug
In non-oop languages you used to have a data type (a structure) and a set of functions to go along with it (a module) - more or less
In an oop language the data and functions are all wrapped up in one entity - the class
Rather than regurgitate the mountain of “why are global bad” posts around the net try http://bfy.tw/xAT
And for a web project globals would be awful
Why ?
Well if 2 people use your app at the same time then which Customer is selected if each selects a different one ?
A global can hold one value
At the very least that should be a Session property - and a Session IS a class so you’re already starting to use OOP 
Thanks, Norman, as usual. What I have been doing thus far is putting Properties like SelectedCustomer (or LayoutWebContainerEmbedded) in the WebPage where they live, and accessing them that way as Public Properties. I have been assuming that such Properties would be tied to a Session, and testing with multiple simultaneous logins seems to bear that out. What I didn’t really think about is that Properties in a Module might not so tied to a Session. Can I safely assume that all instances of Classes are tied to a Session?
Also, regarding Web Apps, in terms of Properties like SelectedCustomer, is it considered more desirable (in terms of OOP) to place that Property in the Session object than in the Class instance it relates to?
It is always best to place a variable or property in the most restrictive scope possible.
Instances are tied to the property that references them and the scope of that property.
I’d suggest that you read or skim a few bits of introductory docs that cover this stuff.
Otherwise you’ll be asking questions forever on here that are already covered.
I’d give the Introduction To Programming book (on http://developer.xojo.com/home) a skim.
It has sections on “Scope” which is exactly what you’re asking about.
One of the main issues with modules in the web is that properties become global to all sessions. That can lead to disastrous collisions. Same thing for using static variables in module methods.
Classes instanciated from webpages will automatically become session aware, so you can use them without extra precautions.
[quote=255773:@Michel Bujardet]One of the main issues with modules in the web is that properties become global to all sessions. That can lead to disastrous collisions. Same thing for using static variables in module methods.
Classes instanciated from webpages will automatically become session aware, so you can use them without extra precautions.[/quote]
What I was looking for. Thanks, Michel.
Static variables in class methods are shared as well. Don’t use them in web apps.
Thanks, Tim. So far I have yet to use static variables, the warning is heeded.
I have a LOT of Modules, but make sure you have to pass every object to them when you call them. Their access is local only, then then return the result to any window that called them. Seems to work OK.
Good point. Global methods (code) in a module are fine. Global variables, not so much. Code runs in the context of whatever called it.
[quote=255771:@Norman Palardy]I’d suggest that you read or skim a few bits of introductory docs that cover this stuff.
Otherwise you’ll be asking questions forever on here that are already covered.
I’d give the Introduction To Programming book (on http://developer.xojo.com/home) a skim.
It has sections on “Scope” which is exactly what you’re asking about.[/quote]
I actually read the Xojo docs relevant to all this before posting here, as far as I can tell, so I understood about scope (other than not understanding the scope of a Module with respect to Sessions, for sure). And I even was aware that OOP developers suggest keeping the scope of a objects and code as narrow as possible. I was just wondering why this was of paramount importance. Specifically with respect to Modules, I noticed Xojo docs saying to make only sparing use of them for Methods and Properties without saying why to do otherwise was such a problem.
So I wanted to find out why this admonition, specifically about Modules. Before starting this conversation here, I did a Google search for “xojo when not to use modules” and didn’t really find much interesting. What got me what I needed was your telling me that Modules were not tied to Sessions and your suggestion to do a search for “why are global variables bad.” The lack of Session awareness has obvious disastrous consequences for Global Properties. And the suggested search turned up very useful info. I clearly was of the ilk that wanted to find ways to keep typing to a minimum when coding, and using Modules seemed to allow that. But I now see that gives rise to a host of other problems around readability and portability of code, even if I’m very careful about when to use this or that Global Method or Property.