> On 11 Oct 2018, at 12:02, Bernd Fröhlich via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > All true, but with globals you can have hard to find side effects. > E.g. i have a lot of buttons and other variables on a lot of forms use > "standard" global variables (bOK, bCancel, bSave, bPrint, bWhetever) so that > I don´t have to define new globals for each form. > > Now and then it happened, that one form changed one of those variables that > was also used by another form. Good luck with finding those bugs because they > only happen now and then and are seldom reproducable. > Using only dynamic variables in my forms saves me from those headaches.
Ok, thanks for that clarification - I can see your reasoning. But just as a bit of philosophical fun, imagine if things were the other way around. Since v1 we had always been using objects and you needed to use accessor commands to do absolutely anything with either data or active form objects. Then one day 4D, after 25 years, 4D came along with this great new feature - a built in wrapper for the object accessors (called a “global variable") that sported a host of great productivity advantages: - maintains state for you without any coding (no laborious “sets” and “gets” anymore) - a single point of reference for the property instead of tens or hundreds of local variables capturing the same property, all with potentially different names and contexts - compiler support for typing to detect bugs “ahead of time” - design time find, replace and rename support - again with a single point of reference I think I might happily pay the price of recreating the variable table for every process (since I never noticed any adverse effect of that) and use naming conventions to avoid conflicts to get those features ! ;) The original selling point of 4D was that it was stateful and that statefullness is what gave us massive productivity gains. Lower level languages like the Microsoft developer platforms, Delphi and even Javascript/Python type environments had the versatility but you had to pay the price in coding according to the classic, stateless styles. 4D is now allowing us to do stuff you could do in these languages but there’s a great big banana skin potentially associated with that transition which is productivity. For example when I started building widgets in 4D, they could be “very nice” but my productivity absolutely plummeted since you need to spend most of the time on designing plumbing systems, event models and custom data structures instead of solving business problems which have traditionally been the 4D developer’s domain. Just a thought. Sometimes it’s difficult to tell novelty value and practical value apart. (Well it is for me at least :-) ) Regards Peter ********************************************************************** 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 **********************************************************************
