Nigel, Wow! I haven't read your whole post yet and I look forward to going through it when I have more time and brain power.
Just a few quick notes: * Globals are bad. Because science. * 4D's approach to scope is....eccentric. * "Global" means "global to all code in the system", which doesn't map onto 4D's approach to scope. *All* 4D variables (apart from most locals) are global in this sense. * Scope is normally a code-level property, in 4D it's normally a runtime property with the process boundary serving as a wall. * A wall with a few big holes called SET PROCESS VARIABLE, GET PROCESS VARIABLE and VARIABLE TO VARIABLE. If you want non-global values in 4D, you have to do it yourself through discipline. The idea of a "module" level of scope is that "only these handful of related methods can touch or see this bit of data directly, evertying else has to ask the module." That's not much like 4D. The closest they come can be implemented with components or workers (in a particular way), but neither is all that close to real modular scope. When thinking about "globals", I'd say it's better to think about "modules" and how to implement them. It's harder in 4D than in other languages and the compiler provides zero support. But it's possible. And, back to what you were saying about IP vars, they're not synonymous with global and process variables are also global. If you have a set of routines that manages, I don't know, a list of open documents in a process - the data is process level: Document_Open Document_CountOpen Document_Close Let's say that they keep some data in arrays or an object. Whatever. If only those three routines can touch the Document_OpenDocref array, then the array is scoped to that "module." If anything can go and get right at that array, then the data is global. In many/most/all? languages, you can scope data to "belonging" to a set of related routines, that's the opposite of "global." The 4D language has no analogous feature, the compiler does nothing, and, in fact, 4D has added several commands down the years to *violate* modularity. But, yeah, globals are bad. They make your life a living hell because someone changes something and now "unrelated" parts of the program break. Of your code pursues an uncommon path and "expected" values aren't where they should be. All bad, all unnecessary. Modular data = Data/Information Hiding = Encapsulation (well, part of encapsulation) ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
