Well, I’m afraid I’ll have to take the pariah role here and politely disagree with you all :-)) - or at least present an alternative perspective in which “globals” play a very powerful and unique part.
Lets think this all through for a moment. As is relevant to this topic, we can notionally consider the data that an application ‘consumes’ in 2 distinct aspects: • persistent data structures • non-persistent data structures The first of these are basically represented by pre-prepared classes which we call “tables". We can instantiate an instance of that class and manipulate that instance implicitly using commands like CREATE RECORD, QUERY and SAVE RECORD. The second are represented - on the one hand - by a library of pre-prepared classes that the ID gives us like forms, form controls, etc and on the other hand by the data oriented language elements, i.e. locals, interprocess globals and process globals (of which 4D data objects are a subset of each). Now, if 4D gave us the facility to scope a process level global variable to an arbitrary set of methods (or even forced us to do so) then it would have effectively have re-invented the concept of the language class as appears in OO languages. You’d have to formally define the class, formally define its properties and methods, formally instantiate it and maintain a reference to the particular instance you’re using at a given moment. You would not be able to support user interface elements implicitly with the class’s data (as we can with native 4D), you’d have to either give your class its own UI and all the supporting methods it needed to drive it (which would only work from within that class) OR create the plumbing to connect an independent form class so that it can be driven by the data in your “tightly scoped” business logic module. Remember, we already have ‘modules’ in 4D which have their own privately scoped variable space in the form of 4D components. So if - on top of that - 4D supported “components within components” I suggest we’d have an unmitigated architectural clutter who’s language structure became increasingly ambiguous and unwieldy. The “living hell” of globals being broadly scoped might actually seem like an attractive problem to have by comparison (for many of us anyway). On 21 Jul 2017, at 14:32, David Adams via 4D_Tech <4d_tech@lists.4d.com> wrote: > But, yeah, globals are bad. They make your life a living hell because > someone changes something and now "unrelated" parts of the program break David, I think you may be impacted by this ‘scoping issue’ disproportionately compared to many developers since you appear to do a lot of “Red Adair” type troubleshooting work where you’re parachuted into a crisis situation and have to start stabilising, refactoring and growing an existing codebase 'back to health’. (Just an observation from your posts - I may be completely wrong on that of course !). I can definitely see how a more formal modular environment would help in that situation. But how many of those databases would have existed in the first place if their original developers had been forced down the more formalised route ? In my own experience of visiting customer sites, not many. Also, I’d posit that your problem isn’t a lack of language support, it’s simply deficient design (by your predecessors) which would in fact have an even more adverse impact in an environment of the complexity you’re promoting. On 21 Jul 2017, at 10:22, Nigel Greenlee via 4D_Tech <4d_tech@lists.4d.com> wrote: > Most code i write now is ‘self contained’ -I attempt to set all values used > in the method is passed in to the code -either as parameters or an object or > a pointer to something so that i end up with something more like a javascript > function Nigel - this would be an admirable objective for the most part if it weren’t for the one big elephant in the room that separates 4D’s “4GL” heritage from its 3GL contemporaries and that is its huge dependence on and leverage of……statefulness ! I urge people not to dismiss it because it’s where we get all our productivity from in the first place. Having thought about this a great deal over the years, I came to the conclusion that we could split our entire codebase into 2 distinct types of method: stateless and stateful. In the case of the former, yes it is a good idea to do as you say and make the code as “self contained” as possible. However in the case of the latter, it’s positively counterproductive because we are dealing with an implicit non-persistent data structure and it’s more efficient just to make that data structure explicit to maintain state between methods. There are also other benefits: • the business logic more auditable because we’re decoupled the data from the code that manages it • we don’t need a myriad of parameters everywhere or random properties buried away in an object • the compiler sees it and can assist with formal verification of our logic • we can use Insider to interrogate its scope of use (I think it’s called “Find in Design” nowadays ;) ) Global variables (not necessarily interprocess, but process at least) are perfect for mapping out these code-based (non-persistent) data structures. It doesn’t matter that they’re scoped globally because that’s the whole point and you can simply restrict their scope logically using naming conventions. Sure it needs a bit of discipline but it’s nothing compared to the discipline that would be required with formally defined arbitrary scoping or classes. Just my 2c and not intended as a contentious response at all as you are all highly experienced so your views count for a great deal. But I usually chip in on this subject to try to keep the ship steered firmly in a 4GL direction when I think it’s in danger of listing into 3GL territory. 3GL’s are good and have some great language features (many of which David Adams lobbys for in 4D) but it just takes about 100 years to get anything significant done in them compared to 4D. I think optimal programming approaches in the existing paradigm can often be far more productive. Regards Peter ********************************************************************** 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
