×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
PHP has a similar feature. In order to use variables from the global scope inside a function, that variable must be either defined as global in the function, or the code must explicitly state that this use of the variable is coming from the global scope. I like that because you can't inadvertently affect other functions by changing the global scope. You must be intentional about it, and advertise it to the rest of the world. Maybe a keyword on the dcl-s or dcl-ds statement would work:
dcl-s a Int(10) Inz(5);
dcl-proc localProc;
dcl-pi *n Int(10) end-pi;
dcl-s a Global;
dcl-s b Int(10) Inz(10);
b = a + b;
return b;
end-proc;
A call to localProc would return 15.
I don't know if I like the idea of declaring which fields would be available by default in all procedures in the ctl-opt because then I don't really know by looking at the procedure which fields are available from the global scope. It might be less coding, but so were the use of conditioning indicators, and I stopped using them in fixed form code in favor of if - endif even with simple yes/no tests, just for readability. I do agree with a ctl-opt that specifies *ALL or *NONE with a default of *ALL. Declarations with the Global keyword would be ignored in the case of *ALL. Maybe the ctl-opt keyword could be something like ExplicitGlobals or NoExplicitGlobals. One issue I would have with Global(field1) making global scope field1 available in all procedures, is how do you turn that off if you don't want it? Maybe the same way as now, by explicitly declaring the variable again in the local scope, but doesn't that get you right back to at least some of the confusion you had teaching globals and local scope before?
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote: -----
To: Rpg400 Rpg400-L <rpg400-l@xxxxxxxxxxxx>
From: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
Date: 11/11/2016 06:12PM
Subject: New RFE for RPG
This is something I have wanted for a very long time - the ability to restrict access to global variables from within subprocedures. Trying to teach folks how to use subprocs and the basics of good modular design is often complicated that they reference globals in error and of course the compiler accepts it.
If you think this would be a good idea please vote for it here:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=97164 <
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=97164>
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
As an Amazon Associate we earn from qualifying purchases.