Just went back and looked at the thread. And, again, I see that there's huge amount of confusion and murk about what constitutes a "global" variable. Flow of control, type, and scope are all basic language design features. Scope in 4D is....peculiar. Scope is typically tied to a collection of methods that share access to a variable. 4D absolutely, positively does not have anything like that. It doesn't have any real notion of data hiding. That's the problem with "globals".
4D has a *runtime* concept of scope where the scope boundary is a process. That's hard to explain to most people. It's also not something that can easily be tested in code at rest since it depends on the runtime context and exact path of execution. It's an inherently unsafe approach compared with well known alternatives. "Modular" programming is a concept from the 1970s, it's nothing new. And it came out of both best practice, the pain of project failures, and some really systematic thinking and research. The ideal goal of scope is to limit the number of methods that can directly touch an item and the lifetime of a variable. Heck, there are languages without even the possibility of global variables. One of the thing that drives people crazy about JavaScript historically is the lack of block level scope. (Not a concept we have in 4D, nor that really makes sense in 4D.) 4D's feature set is actively antagonistic to anti-global scoping: * This is why *SET PROCESS VARIABLE* and *VARIABLE TO VARIABLE* are evil. * With pointers to locals that can escape outside of the current method, you've now got a hard to figure out level of scope. * Double for 4D's reference-based dictionaries (*C_OBJECT*.) The notion that process variables aren't globals and that inter-process variables are globals is wrong. They're both global, but with a specific runtime-only boundary called a process. It's a semi-porous boundary that you can violate without any control at any time with *CALL WORKER/CALL FORM*, *VARIABLE TO VARIABLE*, and *SET PROCESS VARIABLE. *Alternative design include benign messaging and function calls. Also nothing new, decades old. And, as Tim was saying, don't worry about the tiny memory and speed issues, if there are any. I couldn't measure them in V3 or V6 and doubt that you can now. Programmers are always guided by their own worst experiences, and the team developing the server-side of 4D *has different experiences than we do*. They worry about edge cases. A lot. A whole lot. I'm entirely sympathetic to this, they really do need to worry about edge cases. Do we need to worry about the rare cases? Only when we have them. I have them at the expected frequency. Namely, almost never. It's just silly to design to edge cases when you don't have to. With that said, the new *Form* function is *excellent*. Really outstanding, it's easily one of the greatest things I've seen in V17. I'm also happy to see 4D finally come around on this. A day nearly 30 years ago now has always stuck in my mind because it was so awful. Let's just say that the Engineering team back then was *really* hostile to the idea and lost the most knowledgeable programmer I ever worked with as a result. Glad they've seen the light. And thanks to Cannon Smith for the feature request that seems to have been the genesis of the feature. Oh Canada! ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
